What happened to the Claude Code extension on Cursor?
Cursor discovered on October 29, 2026 that its extension marketplace was serving a tampered Claude Code extension. The listing used the official identifier, anthropic.claude-code, and carried versions 2.1.312 and 2.1.313.
Claude Code is Anthropic's AI coding tool, and its VS Code extension is the official IDE integration. Cursor distributes extensions through its own marketplace at cursor.com/marketplace.
Cursor says the malicious builds were available from about 2:27 a.m. to 1:35 p.m. Pacific Time. That 11-hour window was short enough to limit scrutiny but long enough to reach users. The company estimates that at most 5,000 users downloaded the extension.
Eleven hours is short by human standards but long for automated distribution. A single update can reach thousands of machines before anyone reviews it.
Cursor removed the listing and briefly shut down the entire marketplace. It audited access, found no other tampered extensions, rotated its keys and rebuilt the service. It also worked with a hosting provider to take the attacker's server offline.
The tampered builds did not come from Anthropic. Felix Rieseberg, a member of Anthropic's technical staff, wrote on X that a malicious actor had used access to Cursor's marketplace. He said Anthropic's systems, employee laptops and official channels were not compromised.
Anthropic security engineer David Dworken went further. "We were not involved with building, publishing, or hosting this," he wrote on X.
Microsoft's security team reached the same conclusion after reviewing the packages. It confirmed they never appeared in Microsoft's Visual Studio Marketplace or the npm package @anthropic-ai/claude-code. Anthropic told Microsoft that its systems had not been compromised.
Cursor has not explained how the upload happened, and it did not answer WIRED's questions about a breach.
- •2:27 a.m. PT: the tampered builds become available on Cursor's marketplace
- •1:35 p.m. PT: Cursor removes them and takes the marketplace offline
- •October 30: the attacker's server is taken offline with its hosting provider
- •October 30-31: Microsoft, Phorion, OX Security and StepSecurity publish analyses
Why did publisher checks fail to stop it?
This was not an impersonation, because the listing used the real extension name and publisher identity. It also used the familiar update path that developers already trusted.
The uncomfortable part is that publisher reputation offered no warning. Ax Sharma, head of research at Manifold Security, put it plainly. "Checking the publisher name doesn't help when the publisher is real," he said.
Extensions run with the editor's permissions and can reach whatever the developer can reach. They can read source code, write files, start processes and touch cloud credentials. One accepted update reaches every user who installs it.
Marketplaces lean on publisher verification, review and user judgment. None of those controls assumes that the publisher's own upload is hostile. That gap is what the attack exploited.
Review processes tend to focus on new or unknown packages. A modified build of a package that already passed review is harder to spot.
Early reports pointed at Open VSX, a separate open marketplace for VS Code extensions. Phorion corrected its advisory on October 30, and StepSecurity later verified that Open VSX's 2.1.312 build was clean. The malicious artifacts belonged to Cursor's marketplace, not the open registry.
The correction matters for defenders because it shows how quickly an initial attribution can spread. It also narrows the incident to one distribution channel and one set of Cursor users.
Anthropic has said the official build was never affected. StepSecurity reports that 2.1.313 never reached Open VSX, Microsoft's marketplace or Anthropic's own hosts. Anthropic skipped ahead to version 2.1.314 to avoid confusion.
That leaves the marketplace as the weak point in an otherwise trusted chain. Anthropic's code was not modified at the source, but a repackaged copy was published under its name. The upload required access to Cursor's publishing path.
What did the malicious extension actually do?
The tampering was small: a 7,386-byte loader was prepended to the extension's JavaScript bundle. The remaining 3.65 MB of that file matched the clean 2.1.312 extension.js.
The loader ran as soon as Node.js loaded the extension module. It did not wait for a chat, a command or a settings change. "The user doesn't need to interact with the extension for the payload to fire," Phorion CEO Calum Hall told Help Net Security.
The first stage collected host and user details, including the hostname, username, operating system and architecture. Microsoft also lists the home directory, working directory and configured Git email.
The loader searched environment-variable names for terms such as _KEY, TOKEN, SECRET, PASS, AWS and GCP. Microsoft says it kept up to 40 matches and sent the names rather than the values.
Sending names still helped the operator by revealing which machines held cloud credentials or API tokens. That is a targeting list for a follow-up attack.
Next, it tried to create persistent SSH access by appending an Ed25519 public key to the user's authorized_keys file. The key carried the label svc-telemetry, and the loader then tried to enable the local SSH service.
The tunnel command, ssh -N -R '*:0:localhost:22', disabled host-key checking and bypassed the known-hosts file. Phorion describes the goal as long-term interactive access.
Microsoft found that the loader used two SSH identities. One public key authorized access to the workstation, while a separate private key authenticated the outbound tunnel. The loader stored the second key in a hidden temporary file.
For persistence, macOS got a LaunchAgent named com.apple.sysmond. Linux got a cron entry that ran at reboot, and Windows got a scheduled task named SysMon. Windows also received a Startup-folder script as a fallback, according to Microsoft.
Those names mimic legitimate monitoring software, which makes them harder to spot. The scripts retried the tunnel about every 60 seconds, according to Cursor and Microsoft.
The loader also tried to report back to 134.209.82.225 on port 8099. Cursor says the attacker server is now offline, so the beacon and reverse tunnel no longer work.
Cursor published SHA-256 hashes for both tampered builds and the modified extension.js file. Defenders can use those hashes to confirm what reached a machine.
The extension kept working normally, Microsoft notes, so users saw a functioning tool rather than a visible failure. It suppressed command output and silently caught errors, leaving no obvious sign of trouble.
Why did the backdoor fail on most machines?
Enabling SSH requires administrator rights that the extension normally lacks. Cursor says the step failed on most macOS and Windows hosts, so the attacker could not log in.
On macOS, Phorion found a second bug. The script checked whether Remote Login was off without root privileges. The check returned an error, so the script skipped the step that would turn SSH on.
Phorion found the malicious extension on a customer's Mac before Cursor published its notice. That detection gave defenders a head start on a short exposure window.
That saved many machines from a working backdoor, but it did not make them clean. The SSH key and persistence files were still written, even when the tunnel never came up.
Calum Hall called the escape fortunate rather than designed. "Everyone was so lucky here, this was potentially a really dangerous foothold for an attacker," he told WIRED.
Microsoft makes a related point: a running SSH process does not prove that someone logged in. Both the victim's machine and the attacker's server must allow the connection.
The attacker server is now offline, which limits both access and evidence collection. Investigators cannot watch the channel in real time, so they must rely on host artifacts and logs.
The persistence was designed to survive exactly that kind of takedown. A key in authorized_keys does not need the server to exist. It becomes dangerous again if the holder of the matching private key returns.
That is why Cursor told users to remove artifacts rather than simply uninstall. "Uninstalling the extension may not be sufficient," the notice says.
Who is affected, and what should they check?
Cursor's stated scope is narrow: macOS and Windows users who installed or updated to 2.1.312 or 2.1.313. Those users must have downloaded the extension from Cursor's marketplace during the 11-hour window.
Phorion notes that the implant also carried Linux persistence code, while Cursor's notice identified tampered builds for macOS and Windows. WIRED described the listing as affecting all three platforms.
Having one of those versions installed is not proof of compromise. The download source and timing matter more than the version number. Cursor says it plans to contact affected users directly.
The first check is the SSH key that the payload added. On macOS, Cursor's command looks for svc-telemetry in ~/.ssh/authorized_keys. Windows users should also check C:\ProgramData\ssh\administrators_authorized_keys.
Microsoft adds an important caveat: the marker check is a starting point, not a verdict. Investigators should compare the key fingerprint and review process, network and persistence evidence.
Uninstalling the extension is not enough, because the payload drops standalone scripts that keep running. Developers should remove the key, the LaunchAgent or scheduled task, the helper scripts and any tunnel processes.
Credential rotation matters too, especially on machines that ran the extension. Cursor advises rotating secrets and sessions the machine could reach, from a clean device. It also suggests assessing whether the host should be rebuilt.
Phorion suggests checking SSH logs for localhost logins that used the svc-telemetry key. That is the clearest sign of follow-on access.
Microsoft published hunting queries and Defender XDR detections for enterprise defenders. It also advises preserving evidence before cleanup, because the order matters if an organization later investigates.
A missing key is not a clean bill of health. Microsoft says a missing marker should not replace review of installation, process, network and persistence evidence.
- •SSH authorized_keys entry labeled svc-telemetry
- •macOS LaunchAgent com.apple.sysmond and files under ~/.config/.smt
- •Linux cron @reboot entry referencing ~/.config/.smt
- •Windows scheduled task SysMon or Startup-folder sysmon.cmd
- •Outbound connections to 134.209.82.225 on ports 22 and 8099
How serious is the Claude Code marketplace incident?
Five thousand machines is a small fraction of the developer population. The machines themselves are not low-value, because developer laptops often hold source code, SSH keys and cloud tokens. Access to production systems often sits on the same device.
That is why the intended payload mattered more than its success rate. The attacker wanted a durable foothold that survived reboots and editor updates, so persistence was the point.
The limits are real, though, and they matter for risk assessment. The tunnel appears to have failed on most hosts. Cursor found no evidence that other extensions were tampered with. No public report has confirmed a successful login through the backdoor.
The unknowns are larger than the confirmed damage, and they start with attribution. Nobody has publicly attributed the attack, and Cursor has not explained how the listing entered its marketplace. It also did not say whether its own systems were breached.
Those questions matter beyond Cursor, because every extension marketplace inherits the same risk. Publisher verification alone cannot answer that question.
There is also a numbers problem with the 5,000 figure. Cursor's estimate is an upper bound, not a count of confirmed infections. The real number of exposed machines will depend on download records and local evidence.
Security teams should treat the window as a starting point. Any host that ran the extension during those 11 hours needs review. Version numbers alone will miss machines that have since updated.
Notification is part of the risk. A developer who never hears from Cursor may keep a dormant key on a working machine.
What should developers and security teams watch next?
The first thing to watch is Cursor's root-cause report. Users need to know whether the upload came from stolen credentials, a compromised build pipeline or a gap in review.
The second is notification, which Cursor says will go directly to affected users. Enterprises should verify that their developers receive that message and act on it.
The third is version hygiene, starting with Anthropic's move from 2.1.313 to 2.1.314. Developers should update through Anthropic's official channels rather than third-party listings.
Marketplace controls will get more attention, and Microsoft has already published two suggestions. It recommends restricting extensions to approved publishers and setting an installation cooldown for new versions.
A cooldown has a cost, because it delays legitimate fixes as well as malicious releases. Security teams will need to decide how much delay their patch cadence can tolerate.
Behavior-based detection also matters, because a real publisher name defeats reputation checks. Watching for an extension that writes SSH keys or creates startup tasks is more useful.
Sharma also noted that agents and automatic updates increasingly install extensions, rather than people. That shifts the control point from user choice to marketplace policy.
Finally, watch whether this changes how AI coding tools ship updates. These extensions hold unusual access, and they update often. That combination makes marketplace integrity a security control, not a convenience.