Malicious Claude Code Extension in Cursor Marketplace Prompts Developer Security Checks

Cursor and Microsoft have identified tampered Claude Code-branded extension packages distributed through Cursor’s marketplace, with persistent SSH changes making affected machines an incident-response priority.

An open laptop displays programming code on a desk. — A developer’s laptop, illustrating the workstations affected by software supply-chain risks. Photograph: Mahmudul Hasan / Unsplash.

A malicious version of a Claude Code-branded extension distributed through Cursor’s extension marketplace has prompted warnings to developers and security teams. Cursor’s security notice identifies packages labelled Anthropic.claude-code 2.1.312 and 2.1.313 for macOS and Windows, made available during an approximately 11-hour window on 29 October.

The incident concerns the distribution of tampered software through a specific marketplace. It is not evidence that every installation of Claude Code, every Cursor extension or every AI coding tool is affected. Establishing which package came from which source is the first practical task for organisations deciding whether their systems require investigation.

The distribution channel defines the initial scope

Microsoft’s analysis published on 30 October says the malicious packages were not distributed through the Microsoft Visual Studio Marketplace or the official npm distribution. Microsoft also reported that Anthropic had confirmed its systems were not compromised and that it had not developed the malicious packages. The evidence available to Microsoft pointed to Cursor’s marketplace as the affected channel.

Those distinctions are operationally useful. An extension’s displayed name and version can help identify a candidate installation, but the record of its origin is equally important. Teams need enough installation history to distinguish an affected package from a legitimate copy obtained elsewhere, rather than relying on a familiar product name as proof of authenticity.

For software suppliers, the episode also underlines how much trust is placed in redistribution. Users may recognise the original developer’s name while depending on a separate marketplace to deliver the intended package. The security of that delivery process is part of the product experience, even when the original developer’s infrastructure remains outside the compromise.

Persistent changes can outlast an extension

Microsoft describes code designed to collect host information and attempt persistent remote access through SSH. It says successful access depended on privileges, local SSH settings and the attacker’s server configuration. Even where a tunnel failed, malicious keys and persistence artefacts could remain. That makes an unsuccessful connection a different finding from an unaffected endpoint.

This is why removing a visible extension is only one possible part of recovery. A package can create changes elsewhere on a workstation before it is uninstalled. An investigation has to establish what actually executed, what it changed and what remained available afterwards. Those are questions for endpoint evidence and configuration review, rather than assumptions based on whether the editor appears to work normally.

The possible consequences also depend on the workstation’s role. A developer’s computer may interact with repositories, build services and administrative interfaces. That does not establish that any particular downstream system was compromised in this incident. It explains why responders should assess the access available to an affected machine instead of limiting the investigation to the editor itself.

Containment and recovery address different problems

Cursor says it removed the malicious versions, temporarily shut the marketplace, audited extensions, rotated its keys and rebuilt the service. It also worked with a hosting provider to take the attacker’s server offline. Those steps interrupted distribution and the identified infrastructure; they did not automatically remove changes already made on a user’s machine.

The company’s guidance calls for checking installation records and indicators, isolating systems with evidence of execution, removing unauthorised changes and assessing whether a rebuild is appropriate. It warns that uninstalling the extension may be insufficient and advises rotating exposed credentials and sessions from a trusted system. Organisations should use the current vendor notices for the detailed indicators and remediation instructions.

A useful response record should distinguish three outcomes: a package was installed, malicious code executed, or remote access succeeded. They are related findings, but they are not interchangeable. Preserving that distinction helps responders explain the evidence accurately and decide how far an investigation needs to extend.

A wider lesson about software inventory

NIST’s current incident-response guidance, published in April 2025, integrates preparation, detection, response and recovery into cybersecurity risk management. Its relevance here is methodological: organisations benefit from knowing their software and responsibilities before an urgent warning arrives. The publication is a general framework, not an assessment of this particular compromise.

In practice, an organisation that can retrieve extension inventories, installation sources and endpoint history has a much clearer starting point than one reconstructing them after the event. The same records support the later decision to restore access and close an incident. Recovery should be based on what has been checked and corrected, with unresolved questions documented.

The immediate priority remains the affected installations identified by the vendors. The broader test is whether development environments receive the same disciplined inventory and incident handling as other systems carrying sensitive access. Trusted names can help users find a tool; verified distribution and evidence-based recovery are what make that trust defensible.