A poisoned AI coding extension is a supply-chain incident. Respond like one
A tampered AI coding extension reached up to 5,000 developers through Cursor's marketplace in about 11 hours. Editor extensions belong in your software supply-chain controls.
What happened
On 30 October 2026, Help Net Security reported that a tampered build of the Claude Code extension for VS Code-compatible editors, version 2.1.313, had carried a persistent SSH backdoor. The researchers who found it were at Phorion, a macOS security firm.
Cursor said the malicious version was in its extension marketplace for about 11 hours on 29 October, and that it could have reached at most 5,000 users. BleepingComputer gives the window as 2:27 a.m. to 1:35 p.m. Pacific Time. Cursor also said the version "was not developed by Anthropic" and that it found no evidence that other versions or the official distribution were affected.
The reporting differs on where the package sat. Help Net Security's article first says Open VSX, then carries an update from Ax Sharma of Manifold Security disputing that and placing the poisoned listing in Cursor's own marketplace. BleepingComputer, and Cursor's notice as it describes it, point to Cursor's marketplace. We treat the Open VSX claim as unconfirmed.
The mechanism was simple. A short loader was placed at the start of the extension's code, so it ran as soon as the editor loaded the extension, with no click needed. According to the reports, it collected the hostname, username, operating system, Git email and public IP address, and listed the names, not the values, of up to 40 environment variables that looked like keys. It added the attacker's SSH key to the authorised keys file, tried to open an outbound SSH tunnel, and set up persistence on macOS, Linux and Windows. Phorion and BleepingComputer both note coding errors that probably stopped the SSH access working on many machines. Reconnaissance data still reached the attacker's server.
Cursor took the attacker's server offline, pulled the version, temporarily shut its marketplace to audit other extensions and rotate access keys, and rebuilt it. Its advice is to look for an SSH key labelled svc-telemetry, to isolate affected machines, to rotate secrets and sessions, and to rebuild where needed. Uninstalling the extension does not remove the backdoor.
Why it matters
The developer's machine is a production asset. Developers hold cloud credentials, signing keys and repository access. The payload went after exactly that, by listing key-like environment variables. A compromised laptop is a route into build systems and cloud accounts, not only a lost device.
Extensions sit outside most supply-chain controls. Many organisations scan dependencies and lock down build pipelines, yet leave editor extensions to individual choice. An extension updates itself, runs with the developer's privileges and, in this case, ran before any user interaction. That is a gap most software supply-chain programmes do not yet cover.
Familiar names are not a control. The build was a modified copy of a real, widely used extension. Anyone checking the name and the publisher would have seen nothing unusual. Trust has to rest on where an extension is installed from and on who controls updates, not on how it looks.
Fixing the bug does not end the incident. The attacker's tooling kept running after removal of the extension. Teams that treat this as a bad-version problem and move on risk leaving persistent access in place.
Our view is that AI-assisted engineering makes this more pressing, not less. More developers now run agent tooling that has broad access to code, terminals and credentials. That tooling arrives through the same marketplaces. Speed of adoption should not outrun the controls around it.
What we would do
- Check for exposure today. Ask developers who use Cursor or similar editors whether they had the Claude Code extension on 29 October. Search endpoints for the svc-telemetry key in SSH authorised keys and review SSH logs for logins from the local machine using it.
- Treat confirmed hits as compromises. Isolate the machine, rotate every secret it could reach, invalidate sessions from a clean system, and rebuild from a known-good state. Use the indicators of compromise Cursor published.
- Inventory your extensions. Record which extensions are installed across the engineering estate, from which marketplaces, and who publishes them. You cannot govern what you cannot list.
- Set an allow-list and an update policy. Permit a short list of approved extensions, control who can add to it, and decide whether updates are automatic or reviewed. Where possible, pin versions for tools that touch credentials.
- Keep secrets out of the developer environment. Prefer short-lived, scoped credentials and a secrets manager to long-lived keys in environment variables. The less an attacker can read, the less this kind of incident costs.
- Add marketplace compromise to your incident plan. Decide in advance who is told, how affected machines are found and who authorises a rebuild.
None of this is a reason to stop using AI coding tools. It is a reason to run them with the same review and containment you would expect for any software that runs with a developer's access.
Questions we are asked
Is uninstalling the bad extension enough?
No. Cursor's guidance, as reported, is that removing the extension does not remove the backdoor, because the payload can leave standalone scripts that keep running. Check for the attacker's SSH key, isolate affected machines, rotate secrets and sessions from a clean system, and consider rebuilding. Follow the vendor's published indicators of compromise rather than improvising your own clean-up.
Does this mean AI coding assistants are unsafe to use?
Not on this evidence. Cursor said the tampered build was not developed by Anthropic and that it found no sign the official distribution or other versions were affected. The lesson is about the route the code took to developers' machines. Any editor extension, AI-related or not, can be a way in, so manage them with the same care as other software.
Who in our organisation should own extension risk?
Ownership usually sits best with the team that runs developer tooling, working with security. Someone needs to decide which extensions are allowed, who can install them, how updates arrive and who responds when a marketplace is compromised. Without a named owner, extensions are installed individually and nobody sees the exposure until an incident.
Sources
- Claude Code extension poisoned with persistent SSH backdoor — Help Net Security
- Malicious Claude Code extension on Cursor planted SSH backdoors — BleepingComputer