Cursor security breach: Claude Code copies carried malware

Up to 5,000 users potentially received malicious Claude Code builds from Cursor's marketplace cache, Cursor says. The tampered copies were Anthropic.claude-code versions 2.1.312 and 2.1.313, put into circulation on October 29 during the Cursor security breach. Check for those versions and follow Cursor's remediation guidance. Removing the extension alone may not be enough, and recovery also requires checking whether credentials were exposed.

For developers and laptop administrators, this is more than an unwanted extension to remove. BleepingComputer reports that the malicious JavaScript attempted to install persistent SSH backdoors. There is a separate credential problem: secrets left in historical coding-agent traces helped attackers reach Cursor's internal services. A workstation check does not answer the credential question, so both parts need attention.

Check Cursor installations for the tampered Claude Code builds

Cursor's incident update names the affected copies as Anthropic.claude-code 2.1.312 and 2.1.313. The exposure concerns installations or updates obtained through its VS Code extension marketplace during the October 29 window. Cursor says the malicious builds were available for approximately 11 hours. Those versions, that distribution route and that window are the details to check against installation records.

1. Check installation and update history. Establish whether either named version was obtained through Cursor during that window. Check retained installation records; the current version does not establish what previously ran on the machine.
2. Follow Cursor's device-remediation instructions. Its October 30 security notice provides indicators of compromise, remediation steps and scripts for checking systems. The incident update directs customers who installed the tampered builds to that notice and its instructions.
3. Review the messages sent to your team administrators. Cursor says it emailed administrators the specific exposed keys they needed to rotate. It also asked the services that issued those credentials to revoke them.
4. Keep notifications separated by exposure type. Cursor contacted customers about affected traces, credentials, and potentially involved support or business data. A notification in one category does not necessarily describe every part of your organisation's exposure.

Cursor explicitly warns against treating extension removal as the end of the work:

“Uninstalling the extension alone may not be enough.”

— Cursor's incident update

How the Cursor security breach reached the cache

The attacker first got in using a key Cursor had issued to Fireworks AI, its third-party training and inference provider. Cursor says Fireworks exposed the key. With it, the attacker could copy a read-only storage bucket that Cursor shared with the provider.

That bucket held a limited set of historical coding-agent traces, mostly from 2025. The traces came from sessions outside Privacy Mode that Cursor was permitted to use for model training. Some still contained credentials that had escaped redaction. Cursor says traces belonging to fewer than 0.05% of users were exposed; fewer than 0.01% of customers had API credentials exposed.

The credentials in those traces gave the attacker access to selected software-as-a-service tools used by Cursor. The company lists several categories of information accessed through those tools:

• Archived, non-production Cursor source repositories, some of which contained business contact information.
• Limited customer-support information and email conversations, including some credentials that users had sent to support.
• Product usage metrics, along with customer contact details.
• Summaries of some coding-agent conversations.

Cursor's monitoring detected unauthorised activity, and the company started disabling access and rotating credentials. By then, however, the attacker had obtained another credential from an internal system. That credential let the attacker place malicious extension copies directly into the cache serving Cursor's marketplace.

A read-only data exposure became access to other systems because the copied material contained credentials that still worked. Read-only described what the attacker could do in the bucket. It did not limit where the stolen secrets could take them afterward.

What the Claude Code payload attempted to install

The modified extension in the Cursor security breach attempted to establish persistent remote access, rather than just collect a one-time snapshot of the machine. BleepingComputer reports that the payload gathered system information, installed an attacker-controlled SSH key, tried to enable SSH access and configured persistence mechanisms. Removing the extension and determining what that payload managed to do are different tasks.

How often the backdoor actually worked is uncertain. According to BleepingComputer, security researchers found coding errors that likely prevented it from functioning on many Windows and macOS systems where SSH was not already enabled.

I would not use those errors as evidence that a particular machine is clean. The researchers' finding depends on the conditions on the system. Cursor's estimate also counts users who potentially received malicious builds, not confirmed successful backdoor installations. Neither finding answers what happened on an individual laptop.

Where Cursor's Privacy Mode assurance stops

According to Cursor, the Cursor security breach did not expose prompts and code belonging to Privacy Mode users. That assurance is about the historical traces. The extension warning is separate and concerns customers who installed the tampered builds; it is not the same exposure question.

Privacy Mode is not the test Cursor gives for extension exposure. The installation criteria are the named versions, the Cursor marketplace and the exposure window. The distinction works in the other direction, too: receiving a trace-exposure notification does not, by itself, establish that the recipient installed malware.

Cursor also says customer code repositories and the production systems running Cursor were unaffected. The repositories reached through internal tools were archived, non-production Cursor repositories.

This was not a vulnerability in Anthropic's product, either. Cursor says Anthropic did not publish the malicious copies. Open VSX, the marketplace source, never hosted the malware. The point in the distribution path that was compromised was Cursor's cache, not either of those sources.

What Wiz's wider credential-abuse findings establish

Wiz's Black October research describes a wider pattern of attacks against developer infrastructure and credentials that grant access to AI services. It does not identify one vulnerability or dependency that connects all of the incidents. That limit matters when reading the findings alongside Cursor's account.

Wiz says it observed downstream abuse of enterprise credentials attributable to a vendor breach. In the cases it examined, attackers tested stolen keys before substantial inference traffic followed. Those observations support concern about delayed misuse. They do not establish that every exposed Cursor credential went through the same sequence of testing and later traffic.

Wiz publishes the following broader credential-abuse indicators, together with their reported uses and the windows in which activity was observed.

These are not established Cursor-specific indicators. Wiz explicitly says it has no evidence directly linking these addresses to the Black October attacks it names. I'd use them as contextual leads for an investigation, while keeping Cursor's device-remediation checks as the instructions for assessing affected machines. The addresses are not a substitute for those checks.

Cursor rebuilt services, but customer recovery is separate

Cursor says it believes the incident is contained. The last attacker activity it observed occurred on November 1, and that activity was blocked. Containment is the company's assessment; the statement does not claim that monitoring or investigation has ended.

The company's response covers provider access, credential rotation and changes to its internal infrastructure:

• It moved all inference traffic away from Fireworks and cut off the provider's access to shared datasets.
• It rotated exposed Cursor credentials. As a precaution, it also rotated all credentials used across its internal systems.
• It validated other extensions, then reviewed and rebuilt its VS Code extension marketplace.
• It expanded network restrictions where possible and added secret scanning. It also redeployed production infrastructure as a precaution and engaged external forensic experts.

I'd judge a customer's recovery by two separate outcomes: potentially affected workstations have followed the published remediation process, and credentials identified as exposed have been rotated or revoked. Cursor rebuilding its infrastructure does not, by itself, establish either outcome for a customer's laptop or external service account. Check the workstation against Cursor's remediation instructions, then check the exposed-key notices sent to administrators for credentials that still need rotation or revocation.