The Fake Claude Code Extension Was Live for 11 Hours. The Backdoor Is Still on Some Machines.
On October 29, a malicious version of Anthropic’s Claude Code extension was available through Cursor’s VS Code Extension Marketplace for about 11 hours. Cursor says up to 5,000 people downloaded it. The code tried to leave attackers a way back into affected computers, and removing the extension may not remove what it left behind.
The extension looked and worked like the real thing for 11 hours; the persistence was designed to last much longer. Photograph via Unsplash.
The affected package was Anthropic.claude-code, versions 2.1.312 and 2.1.313, for macOS and Windows. Cursor’s notice places the exposure window between about 2:27 a.m. and 1:35 p.m. Pacific time. The extension was not made by Anthropic. Microsoft says Anthropic’s systems were not compromised, and that the affected packages were not distributed through Microsoft’s Visual Studio Marketplace or the official npm package. Current evidence points to Cursor’s marketplace.
Cursor says it removed the versions, shut down its marketplace while it checked for other tampered extensions, rotated keys, rebuilt the marketplace, and worked with its hosting provider to take the attacker’s server offline. That is useful containment. It does not clean the machines that already ran the code.
What the extension tried to do
The malicious JavaScript ran when the extension loaded, before its normal code. The steps below describe what the code attempted, not what necessarily succeeded on every computer. Microsoft’s technical analysis and Cursor’s incident notice document the sequence.
1. It inventoried the machine. The code collected the computer’s hostname, username, operating system, architecture, home and working directories, global Git email, and public IP address. It also looked for up to 40 environment-variable names containing terms such as KEY, TOKEN, SECRET, PASS, AWS, or GCP.
That distinction matters. Microsoft says the code collected the names, not the values. The information could tell an attacker which machines were likely to have credentials, but it is not evidence that the credentials themselves were sent.
2. It tried to leave a spare SSH key. The extension attempted to append an attacker-controlled Ed25519 public key labeled svc-telemetry to the user’s authorized_keys file. On Windows, it also checked the administrators’ authorized-keys location.
In plain terms, it tried to copy a house key and leave it under the doormat. If the local SSH service is available, an authorized key can allow remote login without the usual password prompt.
3. It tried to open a reverse SSH tunnel. The code attempted an outbound connection to 134.209.82.225, asking the remote server to forward traffic back to the workstation’s port 22. On Unix-like systems it used autossh when available, or SSH with a retry loop. On Windows it used a hidden PowerShell loop. The process was designed to try again about every 60 seconds.
Because the workstation initiates the connection, a firewall that blocks unsolicited incoming connections does not necessarily stop the tunnel. But a running tunnel process alone does not prove that someone logged in. The local SSH service, the attacker’s server configuration, and other conditions also had to cooperate.
4. It tried to persist after restart. The payload placed startup mechanisms outside the extension’s folder, where uninstalling the extension would not automatically remove them. On macOS it used a LaunchAgent named com.apple.sysmond.plist, a name chosen to resemble an Apple system component. On Linux it tried to add an @reboot crontab entry. On Windows it attempted a scheduled task named SysMon, with a Startup-folder batch file as a fallback.
5. It tried to report back. A delayed callback attempted to send the collected host details to the attacker’s server on port 8099. Cursor says that server has been taken offline, so the reverse shell and host-detail reporting are no longer functional at that server.
The reassuring part, and the part that should not reassure you
There were mistakes in the attacker’s code. Cursor says enabling local SSH generally required administrator rights the extension did not have, and that the login step would fail in most ordinary macOS and Windows circumstances. The attacker’s server is offline. Microsoft confirms that the environment-variable collection captured names, not their values. No account compromise has been publicly confirmed.
Those points reduce the evidence for successful remote access. They do not make the remaining artifacts harmless.
Expel investigated four customer incidents, all involving Macs. Three began during Cursor’s stated exposure window. In the fourth, a user logged in and opened Cursor at 04:44 UTC on October 30, and the malicious code ran at 04:45, more than eight hours after the marketplace window had closed. The likely explanation is that the extension had been downloaded earlier and did not run until Cursor opened. Organizations that look only at activity between 2:27 a.m. and 1:35 p.m. Pacific on October 29 could miss it.
In one Expel case, the tunnel kept trying to connect for nearly 10 hours on October 30, even though the attacker’s server was reportedly down. Expel also saw a tunnel connect on a Mac where the user was not an administrator, and at least one affected user was a local administrator. Phorion notes that a Mac with Remote Login already enabled, or enabled later, could still have a usable access path.
There is another practical catch: checking only for svc-telemetry is not enough. Expel found a running tunnel in one incident where that key was not present. Cursor also updated its notice on October 30 to add version 2.1.312 and correct its indicators. If you saved hashes from the original notice, get the updated list.
Check machines that run Cursor
Start by checking every machine that runs Cursor, not just devices with activity during the marketplace’s 11-hour window. Review extension installation and update records for versions 2.1.312 and 2.1.313.
On macOS, Cursor’s quick check is:
grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"
Treat “No key found” as a useful check, not a clean bill of health. A missing key does not rule out a tunnel or other persistence artifact.
On Windows, run this in PowerShell to check both locations:
$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" }
Hunt every machine that runs Cursor, not just the ones that installed during the disclosure window. Photograph via Unsplash.
Look beyond the key. Search endpoint and network records for connections to 134.209.82[.]225 on any port, and for command lines containing [email protected][.]225 or -R *:0:localhost:22 with StrictHostKeyChecking=no. Check for files named .stk_ followed by 10 hexadecimal characters, ~/.config/.smt, ~/.config/.smtk, the macOS com.apple.sysmond.plist, the Windows SysMon scheduled task, and sysmon.cmd.
Cursor’s published SHA-256 indicators include the malicious extension.js payload:
ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15
The notice also lists these affected extension package hashes:
Version 2.1.312, macOS: fcbb327e38e61c4fec795e0d0591f52cd1014b813d20a5912104953c3a17c364
Version 2.1.312, Windows: 3de1722901165769893bef57c72594e9a54459faa23f3091b136b79966edd081
Version 2.1.313, macOS: 80402fdcad8799285fd93044976973ca000da7995fb93363f819bb8e4f84ee6c
Version 2.1.313, Windows: 6786ec90cbd45949695bd7805c9fbb26cfc91bc5fc897de0183d9bcb9cb21731
If a machine shows evidence of execution or persistence, isolate it and preserve relevant evidence. Cursor provides remediation scripts and platform-specific instructions. Its macOS script should be run as the affected user; its Windows script should be run in PowerShell as Administrator. Remove confirmed malicious keys, startup items, tunnel processes, and temporary files. Cursor says its scripts exit with a non-zero status if artifacts remain.
Then rotate credentials and revoke sessions that were accessible from the affected machine, using a trusted device. To check whether anyone actually logged in, Phorion recommends reviewing SSH logs for localhost logins using the svc-telemetry key. Preserve unrelated authorized keys and legitimate startup tasks during cleanup.
The bigger issue is where developers place trust
This incident came about a week after the October 21 LiteLLM 1.107.0 supply-chain compromise, which Expel also investigated. The same day this extension story surfaced, a separate Cursor security issue involving its embedded browser and AI agent was also reported. That does not prove a common actor or cause. It does make the developer-tool ecosystem a reasonable place for security teams to look more closely.
The attacker did not compromise Anthropic, npm, or Microsoft’s marketplace, according to the evidence reported so far. The malicious extension used a familiar product name in a marketplace developers trusted. The brand did the work of lowering suspicion. A separate Yoba campaign used fraudulent GitHub projects and installers disguised as ChatGPT and Claude desktop applications. The AI brand itself is now part of the lure.
The operational fix is not glamorous. Track which extensions are installed on developer machines. Restrict installation to approved publishers. Consider a cooldown before new extension versions can be installed. Cursor’s enterprise hardening guidance now recommends controls of this kind. Make sure developer workstations are covered by endpoint detection, and review outbound connections from IDE processes.
Most importantly, do not let the disclosure timeline define the hunt. The marketplace window lasted 11 hours. Expel’s incident data shows that the first observed execution can happen later, when a developer opens the editor. The extension may be gone from the store while its leftover files are still sitting in authorized_keys or a startup folder.
For more practical technology coverage, visit the TechTime Radio blog, browse the episodes, or listen live.