The Claude Code Extension Backdoor Outlasted Every Default Install Delay: What to Check and Change

The extension that backdoored up to 5,000 developer machines this week carried Anthropic’s real extension ID, so the usual advice (“check the publisher before you install”) would not have stopped it. A modified build of anthropic.claude-code, versions 2.1.312 and 2.1.313, sat in Cursor’s extension marketplace from about 2:27 a.m. to 1:35 p.m. Pacific on October 29, and anyone with auto-update on could have pulled it without clicking anything (Cursor security notice). Cursor says the malicious versions “were not developed by Anthropic,” and Microsoft’s analysis confirms the package never appeared in the Visual Studio Marketplace or on npm (Microsoft Security). The thing that was compromised was the distribution channel, not the vendor.

That distinction drives everything below. First, how to tell whether one of your machines took the build and what to clean up. Second, the install controls that already exist in Cursor and VS Code, and the uncomfortable fact that their defaults are shorter than the time it took to catch this one.

What the loader actually did

The tampered build ran a small loader ahead of the real extension code. OpenSourceMalware’s Jenn Gile counted 66 lines of it, and noted that “anyone who has their Claude Code instance set to auto-update could have consumed the malware” (The Hacker News). Microsoft’s write-up lays out the sequence:

• Reconnaissance. Hostname, username, OS, home and working directories, the global Git email, and the names (not values) of up to 40 environment variables containing KEY, TOKEN, SECRET, PASS, AWS or GCP.
• An SSH key. An Ed25519 public key with the comment svc-telemetry appended to authorized_keys, plus an attempt to switch on the local SSH service.
• A reverse tunnel. SSH to 134.209.82.225 with a remote port forwarded back to the workstation’s port 22, retried every 60 seconds, using autossh where available and a hidden PowerShell loop on Windows.
• Persistence. A LaunchAgent at ~/Library/LaunchAgents/com.apple.sysmond.plist on macOS, a scheduled task named SysMon on Windows (with a Startup-folder sysmon.cmd fallback), helper files in ~/.config/, and a private key in a hidden file matching .stk_ plus ten hex characters.
• A beacon to port 8099 on the same IP, sent later, carrying the host details and variable names.

Two details deserve more attention than they got. The environment-variable sweep collected names, not secrets, but a list like AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, OPENAI_API_KEY tells an operator exactly which cloud, which CI system and which model provider sit on that laptop. It is a targeting list for the next stage. And the tunnel only needs an SSH server to answer on port 22. Cursor says enabling SSH generally fails on macOS and Windows without admin rights (The Hacker News), which is good news for a default laptop and no news at all for a developer who already runs OpenSSH Server for remote work. On that machine, the key and the tunnel are the whole attack.

This is also why an AI coding extension is such an attractive wrapper. It is expected to read your repository, run commands and sit inside the shell where your tokens live. A loader hidden in it looks like the extension doing its job. The same logic ran through the “verified” plugin flaw this site covered in September, where the fix was pinning to a commit hash rather than trusting a name.

Checking a machine, and cleaning it properly

Start with whether the build was ever installed. Look at the installed Claude Code extension version in Cursor; anything at 2.1.314 or later is the clean release Anthropic pushed to Open VSX and the Visual Studio Marketplace on October 30 (The Hacker News). But a current version number proves nothing about what ran on October 29, so check the artifacts directly.

On macOS (Cursor’s own check, plus the persistence files Microsoft lists):

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "KEY PRESENT"
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk 2>/dev/null
crontab -l 2>/dev/null | grep -n "\.smt"

On Windows, in PowerShell:

Select-String -Path "$env:USERPROFILE\.ssh\authorized_keys" -Pattern "svc-telemetry"
schtasks /query /tn SysMon /v /fo list
Test-Path "$env:USERPROFILE\.config\smt.cmd"
Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"

If your fleet runs Defender, Microsoft published advanced hunting queries for the IP, the file hashes and the SysMon task, and it treats a hit as a lead to investigate, not proof of compromise. Firewall and proxy logs showing any connection to 134.209.82.225 are the fastest network-side signal.

If anything matches, the order of operations matters more than the speed:

1. Isolate first, preserve evidence second, clean third. Microsoft’s guidance is to “isolate devices with evidence of loader execution or backdoor installation” and to capture state before cleanup.
2. Remove the extension and the artifacts separately. Uninstalling the extension does not touch files written outside its folder; OX Security puts it bluntly: “uninstalling the malicious extension may not be sufficient” (OX Security). Delete the exact authorized_keys line after checking the fingerprint Microsoft publishes, kill any running ssh or autossh tunnel processes, and remove the LaunchAgent, cron entry, scheduled task and helper files.
3. Inspect before deleting by name. The persistence objects are named to look like monitoring software. Microsoft’s advice is to check each startup object’s configured action, because “names alone are not sufficient.”
4. Rotate from a different machine. Every credential whose variable name appeared in that shell, plus SSH keys, Git tokens and cloud sessions reachable from the host, should be rotated from a known-clean device. Cursor publishes cleanup scripts for macOS and Windows on its notice; read them before running them, which is Microsoft’s advice too.

The setting that would have mattered

Cursor already ships the control that fits this incident. Team admins can set a Marketplace Install Cooldown that will “defer extension installs and updates until a marketplace version has been published for a minimum number of hours,” and individual users can set extensions.installCooldownHours when the team hasn’t enforced one (Cursor docs). The default is 0.

The malicious build was available for roughly 11 hours. On Cursor’s description of how the cooldown works, a team cooldown of 24 hours would have kept auto-update from installing it on any machine that honored the setting, because the version was pulled before it ever aged past the threshold. A cooldown measured in hours costs you a day’s delay on legitimate updates, which for a coding extension is almost never urgent.

VS Code has a version of the same idea. Release 1.125 on June 17 made the extension update delay configurable through extensions.autoUpdateDelay, and by default “VS Code waits two hours before installing extension updates” (VS Code 1.125 release notes). Two hours is better than zero, but it would not have covered an 11-hour window. Both editors ship a delay; neither ships one long enough for the way these incidents actually get caught, which is by a researcher noticing something odd and a vendor confirming it the same day.

The other two controls Cursor documents are worth turning on, with honest expectations:

• Allowed extensions. Admins can restrict installs to approved publishers or extension IDs, in the dashboard or through the MDM key AllowedExtensions. That shrinks your surface, but note what it would not have done here: anthropic.claude-code is exactly the ID you would have approved.
• Signature verification. Enterprise teams can require valid Open VSX extension signatures before install. Cursor has not said whether this setting would have rejected the tampered build, so treat it as a sensible layer, not as the fix, and ask your account rep the direct question.

Cursor’s own documentation states the limit plainly: cooldown and signature checks “are client-side install controls” that “complement, but do not replace, marketplace-layer analysis and blocking.” In other words, the marketplace has to catch the bad version; your settings only buy time for that to happen. That is the argument for a long cooldown rather than a short one.

The question nobody has answered yet

Neither Cursor nor Anthropic has said how a build under Anthropic’s identity got into Cursor’s marketplace. BleepingComputer asked both companies and had no answer at publication, and early reports that Open VSX, npm and the Visual Studio Marketplace were also hit were later disproven, with Cursor confirmed as the only distributor (BleepingComputer). What Cursor did say is that it shut the marketplace down, audited access, rotated keys and rebuilt it before bringing it back.

Until the root cause is public, the practical reading is this: an editor fork that proxies its own extension marketplace is a separate supply chain from the one the extension author controls. Anthropic shipping a clean release does not protect you if the channel between Anthropic and your editor can be written to by someone else. That is the same lesson as the five supply chain attacks in twelve days back in March, and the same reasoning behind validating Claude Code mods before they run and reading the scripts inside an Agent Skill before you install it.

For a team running Cursor, the short version fits on one line of an admin checklist: set the install cooldown to 24 hours, restrict installs to an allowlist, turn on signature verification if your plan has it, and add authorized_keys changes to whatever endpoint monitoring you already run. None of those settings would have made headlines on October 29. All of them would have made it a non-event.