Claude Code tampered with in Cursor: Why an update is not enough

A familiar name, a routine update and an additional backdoor: On 29 October 2026, a tampered Claude Code extension was available in Cursor’s extension marketplace. It attempted to give an attacker persistent SSH access to developers’ computers. For affected businesses, the response therefore goes beyond installing the next update: what matters is what executed on each workstation and which accounts it could reach.

This is a serious incident. Its confirmed scope is also narrower than some early headlines suggested: a tampered package in Cursor’s marketplace, not an established breach of Anthropic as a whole.

At a glance

• Check extension, version and source together: the identified package is anthropic.claude-code version 2.1.313 from Cursor’s marketplace.
• The malicious code could execute when the extension loaded. Starting a Claude conversation was not required.
• Failed SSH access does not automatically make a computer clean. Keys and startup files may still remain.
• Separate investigation of the workstation from restoration of its accounts. A clean extension does not establish that the host is trustworthy.

Research checked: 30 October 2026, 15:33 CET. We compared the vendor notice, updated researcher reports and Microsoft documentation. This is editorial source research; we did not execute or forensically analyse the malicious package ourselves. The graphics are our own schematic illustrations. German is the editorial source version.

What Cursor confirms — and what remains unresolved

Cursor’s security notice identifies an exposure window on 29 October of approximately 2:27am to 1:35pm Pacific Time, equivalent to 09:27–20:35 UTC. Cursor reports at most 5,000 affected users. This is the vendor’s exposure estimate, not a count of proven successful remote logins.

The vendor says it blocked the package and distribution, audited the marketplace and rebuilt it after rotating keys. It also says the hosting provider took the attacker’s server offline. The reviewed sources do not conclusively establish how the tampered package entered distribution.

Why we do not identify Open VSX as the origin

Early reports attributed the package to Open VSX. OpenSourceMalware explicitly corrected that attribution, identifying Cursor’s marketplace as the origin. The Hacker News also records this correction.

Some technical reports still carry the earlier attribution. We use their technical observations as such; their registry wording is not independent evidence of wider distribution. A version disappearing from a registry would not, on its own, prove that its package was malicious.

The current sources compared here provide no equivalent evidence of compromise for npm, Open VSX or Microsoft’s Visual Studio Marketplace. This is not a blanket assurance about every installation: provenance and the actual package still need to match.

How an editor extension was meant to become a remote access route

OpenSourceMalware’s technical analysis describes a loader prepended to extension.js. It runs before the normal extension code. The expected application can therefore keep working while the added code has already started.

Three parts of the chain matter for response:

1. Prepare access: add an attacker-controlled public SSH key to the user’s configuration.
2. Make the service reachable: establish an outbound reverse SSH tunnel forwarding connections to the local SSH service.
3. Return later: use platform-specific startup mechanisms to restart the tunnel.

SSH is a legitimate encrypted remote-access protocol. A reverse tunnel starts from the affected computer. Blocking unsolicited inbound internet connections therefore does not answer the whole exposure question. Outbound connections, the local service and authentication to it also matter.

The researchers also distinguish environment-variable names from values. The initial beacon they examined includes matching variable names, rather than directly sending their values. “All API keys were stolen” would be an unsupported escalation of that finding. Successful interactive access could, however, expose additional data. Whether that happened requires investigation of the individual host.

Why a lack of administrator rights is not an all-clear

Phorion explains a flaw in the macOS branch: without administrator rights, checking Remote Login can return an error message that the malware misinterprets. If SSH is not already running, the intended enablement may consequently be skipped. An already active service changes that situation.

These are separate findings: malicious code executed, persistence installed, tunnel connected and successful login should not collapse into one yes/no field in an incident report. Failure at one stage does not exclude the others. Equally, the presence of one indicator does not establish everything the attacker may subsequently have done.

What IT and security should establish together

The following is our suggested structure for an internal response. Check specific cleanup details against the current vendor notice and your incident-response procedure.

1. Build an evidence-based list of exposed workstations

Record editor, extension ID, installed or previously executed version, platform and source. Include managed remote development environments where the extension actually ran. “We use Claude” is too broad a search criterion.

For each workstation, record the basis of the assessment: installation history, a preserved package, endpoint telemetry or merely a user’s recollection. A version updated today does not tell you which version ran yesterday.

2. Preserve evidence before removing it

The vendor notice provides indicators and cleanup guidance. Search leads include the SSH key comment svc-telemetry, 134[.]209[.]82[.]225, hidden configuration files and unusual startup entries. Individual names can be ambiguous; correlate keys, paths and timestamps.

Preserve relevant files and logs under your response procedure. A single negative check is not forensic clearance: artifacts may be missing, changed or already removed. We therefore do not infer “unaffected” solely from an unsuccessful search command.

3. Establish the possible reach into other systems

For each affected user, ask which repositories, cloud accounts, package registries and administrative systems were accessible. Distinguish stored credentials, active sessions and permissions that would require further systems to become usable.

This list determines which owners must join the response and which accounts need revocation or renewal. Possible access is not proof of data theft; it is a reasoned scope for investigation.

4. Document recovery and the decision to restore access

Define who decides on isolation, cleanup or rebuilding, and what evidence is needed before returning the machine to service. Renew affected credentials from a trusted system. Record the outcome, unresolved questions and limitations of the available logs.

“The extension is updated” should not be the only closure criterion. Separate decisions for the workstation, identities and potentially reachable systems are more useful. They make it visible when the computer is operational again but a cloud session is still under review.

What businesses can learn about their software supply chain

Approval of an AI tool often addresses contracts, data processing and permitted uses. This incident adds another layer: which executable code reaches the workstation through which update channel?

Microsoft documents that the extension host has the same permissions as VS Code. Extensions can, for example, change files and launch processes. This general architecture explains their potential reach; it does not establish exposure through Microsoft’s marketplace in this incident.

For your next review, we suggest these concrete decisions:

VS Code supports centrally managed extension and version rules. Microsoft also explains their limits: for locally supplied VSIX packages, the rules inspect declared identifiers. They do not prove provenance or automatically restrict runtime permissions. Verify enforcement for each editor rather than assuming one configuration applies to every fork.

A useful internal outcome could be continued productive development with defined installation sources, separately controlled production access and an owner for extension security alerts. That is more actionable than a blanket AI ban or approval with no named responsibility.

How this differs from an AI agent exceeding its task

Our report on the AISI supply-chain attempt concerned an agent acting beyond its assigned task. This case concerns tampered extension code. A carefully written prompt would not have controlled the prepended loader.

Access, monitoring and ownership connect the two subjects for businesses. Their causes and effective controls still need to remain distinct. Treating every problem as “AI hallucination” could send an investigation toward the model when the entry point was software distribution.

In Kopexa, you can connect organisational follow-up with risks, actions, owners and evidence. That does not replace endpoint detection or forensic investigation. It helps turn technical findings into traceable work: which action remains open, who decides, and what demonstrates completion? Your process from incident to approved follow-up is a concrete starting point for a Kopexa demo.

Which questions still lack established answers

The sources reviewed do not establish the complete insertion method, successful access to every exposed computer or comprehensive data theft. Taking infrastructure offline and removing a package are important responses, but they do not replace investigation of packages that already executed.

Our criterion for further updates remains: what new finding supports the claim, and does it change exposure or the required response? Further original reports may change this assessment.