A backdoored build of the Claude Code for VS Code extension sat on the Cursor Marketplace with a persistent SSH backdoor baked in — version 2.1.313 is the one to look for. Security firm Phorion spotted the implant, Cursor has pulled that release from its marketplace, and the matching NPM and VS Code builds of 2.1.313 came down from their registries too. Everything below is written for people who don't live in a terminal all day, because the interesting part isn't the malware — it's how easily an add-on becomes a key to everything you own.
What happened
An editor extension is a key to your whole machine
Extensions are the plug-ins that bolt extra features onto editors like VS Code and Cursor. The catch is that they inherit the permissions of the editor and of whoever is running it. So the second an extension's code loads, it can read your files, your source code and your developer tools. No "allow access?" popup, no warning. Think of it as hiring a locksmith who gets handed a copy of every key in the building before you've even read the contract.
The malicious code ran before you clicked anything
The compromised build had a small block injected at the very top of its `extension.js` file — an immediately invoked function expression, which is just a chunk of code that runs itself the moment the file is loaded. That injected prefix pulled in standard Node.js modules (`child_process`, `fs`, `os`, `path`, `http`, `crypto`) and fired before the extension's own startup callback ran. You didn't have to open a Claude panel or type a single prompt. Launching the editor was enough. The rest of the bundle looked completely ordinary: standard activate and deactivate exports, UI code, the usual Claude Code and VS Code strings.
Stage one: a spare key under the mat
The payload's first job was to create `~/.ssh` if it didn't exist, then append an attacker-controlled Ed25519 public key to `~/.ssh/authorized_keys`, setting permissions to 0700 on the folder and 0600 on the file. In plain terms: `authorized_keys` is the guest list for SSH — the protocol that lets someone log into a computer remotely. Adding a public key is like adding a name to that list. Whoever holds the matching private key walks straight in afterwards, no password needed. The key carried the comment `svc-telemetry`, which is designed to look like dull monitoring traffic. That's the disguise.
If you go hunting, note one detail: the script checked whether the string `svc-telemetry` was already in the file, not whether the key itself was. Verify the actual key fingerprint instead of trusting the tag.
The macOS bug that accidentally broke the front door
Next, the payload tried to switch on Remote Login, which is what macOS calls accepting SSH connections. There's a built-in way to read that state: `systemsetup -getremotelogin`. The setup logic assumed a standard user could check it without root. It can't. Run as a normal account, the command throws an administrator-access error and exits with status 0 instead of printing `Off`. Because the script only ran its enable step when the output matched `Off`, it skipped that step entirely. On a Mac that wasn't already running SSH, the inbound door never opened — even though the key and the persistence bits still landed on disk.
The implant includes setup and persistence logic for Linux and Windows as well, and it beacons host reconnaissance back to its operator. So even with the macOS bug, this is still live malware with a long-term goal: interactive access to machines that hold code.
What it means for you
Home: your personal laptop
If you installed Claude Code for VS Code to mess around with AI-assisted coding on your own machine, the damage is usually contained — a stranger's key could have been added to your SSH guest list, which is bad but fixable. Rotate anything that lives in plain text near your code: saved passwords in `.env` files, API keys, browser sessions. Ten minutes of tidying beats a month of worry.
Work: a developer's laptop
This is the worst-case scenario, and it's the one Phorion is loudest about. A developer's machine typically holds source code, cloud credentials and SSH access to production servers. If that laptop ran 2.1.313, treat it as a security incident rather than a cleanup job — pull the key, rotate credentials, and bring in whoever handles incident response.
Business: agencies and contractors
If a freelancer or agency installed the extension on a machine that touches your site, your shop or your customer database, you're allowed to ask one blunt question: what version, and did you check `authorized_keys`? You don't need to be technical to request an answer in writing.
Study: shared and lab computers
Students often install coding helpers on shared university or library machines. A backdoor on a shared computer affects everyone who uses it, not just the person who installed it. If you've done this, flag it to whoever runs the lab — most IT teams would much rather hear it from you than discover it later.
Creative work and side projects
Designers, video editors and writers who installed the extension inside Cursor to help with scripts, captions or small automations are in the same boat. The exposure is whatever files were sitting in your project folder when the editor opened — which might include client assets under NDA.
Income: anything tied to your accounts
If your freelance income runs through accounts you've saved on that machine — hosting, payment dashboards, code repositories — assume the credentials were reachable and change them. It's annoying. It's also a lot cheaper than explaining a breach to a client.
How to try it right now: check your own machine
You don't need a security subscription for this. All of it is free, and most of it takes under five minutes.
Step 1 — Find your version. Open VS Code or Cursor, go to the Extensions panel, find Claude Code and look at the version number. If it says 2.1.313, keep going. If it's something else you installed on purpose, you're on a different build — still worth doing the next two steps, just without the panic.
Step 2 — Read your SSH guest list. On macOS or Linux, open Terminal and run `cat ~/.ssh/authorized_keys`. Look for `svc-telemetry`, but don't stop there: check the fingerprint of each key rather than trusting a comment, since comments are easy to fake.
Step 3 — Check the locks. Run `ls -ld ~/.ssh` — it should show `drwx------`. Run `ls -l ~/.ssh/authorized_keys` — it should show `-rw-------`. If the permissions are wide open, someone has been fiddling.
Step 4 — Check whether Remote Login is on. On a Mac, go to System Settings → General → Sharing → Remote Login. If it's switched on and you never turned it on, that's a red flag.
Step 5 — Borrow a translator. If a line of shell output looks like gibberish, don't guess. Paste it into a free AI assistant — the ones at MyKreaTool are free and good at turning command output into plain English — and ask it to explain what you're looking at and whether it's normal.
Step 6 — If you find the key. Delete that line from `authorized_keys`, turn Remote Login off if you didn't switch it on yourself, change the passwords and tokens that machine could reach, and escalate to your security team if it's a work device.
Upsides and what changes
There's no silver lining to a poisoned build shipping through a marketplace people trust. But advisories like this one do shift behaviour in ways that stick. Expect teams to pin extension versions instead of always grabbing the latest, to review what a plug-in can touch before installing it, and to add `authorized_keys` to the list of files worth watching. The macOS quirk is a useful reminder that attackers make mistakes too — a single wrong assumption about admin rights quietly disabled the inbound half of the attack. That's luck, not protection. Don't build your security plan around the next criminal's typos.
Limitations
Be clear about what this advisory does and doesn't tell you. Phorion's write-up dives deepest into macOS, with the Linux and Windows paths described in less detail, so if your fleet is mostly Windows you're working with less information than a Mac admin is. The bug that blocks SSH enablement on macOS reduces impact there — but the key and persistence logic still executes, and the implant still phones home with host reconnaissance, so "the backdoor didn't open" isn't the same as "nothing happened." Not finding `svc-telemetry` in your `authorized_keys` doesn't prove you're clean either, since the check depends on file permissions and on whether anyone edited the file afterwards. And none of this tells you how the build got compromised in the first place. If you're dealing with a business machine or client data, get a professional involved rather than self-diagnosing from a blog post.
Conclusion: One Action for Today
Open Terminal and run `cat ~/.ssh/authorized_keys`. That's the whole task. If you recognise every key on that list, you're probably fine and you've learned something about your own machine. If there's a line you can't explain — especially one tagged `svc-telemetry` — delete it, turn off Remote Login, and start rotating the credentials that machine could reach. One command, once, today. The next backdoored release won't announce itself either.
Comments 0