Cursor Claude Code Extension: Enterprise Warning

The cursor claude code extension incident shows why AI coding extensions should be treated as privileged software, not harmless productivity add-ons. On October 29, 2026, a maliciously modified extension was available through the Cursor VS Code Extension Marketplace, prompting immediate exposure reviews for engineering and security teams.

What happened to the cursor claude code extension in Cursor

Cursor reported that maliciously modified versions of the Anthropic.claude-code extension were distributed through the Cursor VS Code Extension Marketplace on October 29, 2026. The modified extension was not developed by Anthropic.

Cursor identified versions 2.1.312 and 2.1.313 as malicious for Windows and macOS. The versions were available from approximately 2:27 AM to 1:35 PM Pacific Time, which corresponds to approximately 09:27 to 20:35 UTC on October 29, 2026.

Sophos reported that the affected package was Anthropic.claude-code version 2.1.313 and that up to 5,000 users may have been affected. That figure is an estimate of potentially affected users, not a confirmed count of compromised machines or successful intrusions.

Cursor said it removed the malicious version, shut down the marketplace, audited access, rotated its keys, and rebuilt the marketplace. Cursor also reported no evidence that other extensions were tampered with.

The immediate enterprise question is not whether the extension was popular or useful. It is whether a package installed during the exposure window received the same trust and machine access as approved development software.

Which versions and machines were in scope

The reported scope includes Claude Code extension versions 2.1.312 and 2.1.313 on Windows and macOS during the October 29 exposure window. Cursor reported no evidence that other extension versions or the official distribution were affected.

Teams should begin with version and installation records rather than relying on memory. Review endpoint management data, developer workstation inventories, extension manifests, and marketplace installation telemetry for the two affected versions.

• Reported malicious versions: 2.1.312 and 2.1.313.
• Reported operating systems: Windows and macOS.
• Reported Pacific Time window: approximately 2:27 AM to 1:35 PM on October 29, 2026.
• Reported UTC window: approximately 09:27 to 20:35 UTC on October 29, 2026.
• Potential scale reported by Sophos: up to 5,000 users.

A machine outside those versions or windows is not automatically in scope based on the supplied incident reports. Conversely, a machine inside the window should not be declared compromised without checking local evidence, because the reports describe attempted malicious activity and potential exposure rather than universal successful access.

The distinction between the marketplace path and the official distribution matters. Cursor reported no evidence that the official distribution was affected, but enterprise teams should still record which distribution channel each developer used and preserve that evidence for incident review.

What the malicious payload attempted to do

The malicious extension attempted reconnaissance, SSH access, and persistence on developer machines. Its reported behaviour was designed to collect host context and create a route for continued access, although the available facts do not establish that every attempt succeeded.

The extension collected host and user information including the hostname, username, operating system, architecture, home directory path, environment variable names, working directories, configured Git email, and public IP address. Environment variable names can reveal the presence of cloud, source-control, deployment, or other development tooling even when their values are not collected.

The payload attempted to add an attacker-controlled SSH key to the local authorized_keys file. An authorized_keys file lists public keys permitted to authenticate to an SSH account, so an unauthorized entry can provide a durable access mechanism if the local SSH service is reachable and the key is accepted.

The extension also attempted to enable the local SSH service and open a reverse SSH tunnel. A reverse tunnel is an outbound connection from the developer machine that can provide a remote route back into that machine, which matters because many corporate networks allow outbound traffic more readily than inbound connections.

For persistence, the payload attempted to use a macOS LaunchAgent or a Windows scheduled task, with a startup-script fallback. Persistence means mechanisms that restart malicious code after a reboot, login, or process termination.

Background scripts reportedly retried roughly every 60 seconds. Cursor said the attacker server was taken offline with help from its hosting provider, so the reverse shell and host-detail POST were no longer functional according to Cursor. That reduces the reported live capability but does not remove the need to investigate local changes.

Why uninstalling the extension is not a complete response

Uninstalling the malicious extension may not be sufficient because the payload could drop standalone persistence scripts that continue running after the extension is removed. Removal should therefore be treated as one containment step, not as proof that a developer machine is clean.

Security teams should review the following indicators and changes on potentially exposed Windows and macOS systems:

• Unexpected entries in the user’s authorized_keys file, especially an attacker-controlled key labelled svc-telemetry.
• Unexpected changes that enable or alter the local SSH service.
• Unknown macOS LaunchAgents, Windows scheduled tasks, startup scripts, or background processes created during or after the exposure window.
• Outbound SSH connections, reverse-tunnel activity, or repeated connection attempts at roughly 60-second intervals.
• Unexpected access to working directories, Git configuration, environment metadata, or developer home directories.
• Endpoint, network, and identity telemetry that can connect the extension installation to later process, authentication, or network events.

The svc-telemetry label is a useful source-provided indicator, but its presence should be checked alongside file timestamps, process history, SSH logs, task or LaunchAgent records, and network data. Its absence does not by itself prove that no other local modification occurred.

Teams should separate indicators of attempted activity from evidence of successful access. The supplied reports describe collection attempts, SSH-key modification attempts, service enablement, reverse-tunnel attempts, and persistence attempts; they do not establish that every affected host accepted the key or connected successfully.

Enterprise response checklist for AI coding extensions

Enterprise response should combine software inventory, endpoint investigation, credential protection, and a documented rebuild decision. Security should own the incident process, while platform and engineering teams provide installation, identity, and workstation evidence.

Control area	Question to answer	Immediate action
Extension inventory	Which developers installed Anthropic.claude-code through the Cursor marketplace?	Export extension names, versions, users, devices, and distribution channels from endpoint and developer-tool records.
Version and installation-window review	Did version 2.1.312 or 2.1.313 appear on Windows or macOS during October 29?	Compare installation and update timestamps with both the Pacific Time and UTC exposure windows.
Host isolation	Could a potentially exposed machine continue reaching sensitive systems?	Apply the organisation’s incident process to isolate high-risk hosts while preserving relevant evidence.
Persistence removal	Did the payload alter authorized_keys, SSH settings, LaunchAgents, scheduled tasks, or startup scripts?	Inspect and remove unauthorized persistence only through approved forensic and remediation procedures.
Credential and session rotation	Could host, Git, cloud, deployment, or session credentials have been exposed?	Assess and rotate relevant keys, tokens, passwords, and sessions based on evidence and privilege.
Rebuild decision	Can the host be trusted after investigation, or is its integrity uncertain?	Document the evidence threshold for cleaning, rebuilding, or replacing the developer machine.
Telemetry review	What happened before, during, and after installation?	Correlate endpoint, network, SSH, identity, marketplace, and source-control telemetry.

A rebuild decision should not be automatic for every potentially exposed device, but it should be explicit. If a machine has unexplained persistence, missing telemetry, or evidence of unauthorized access, the cost of preserving trust in the host may exceed the cost of rebuilding it under the organisation’s incident procedures.

Credential rotation should also be risk-based rather than ceremonial. A developer workstation may hold Git credentials, cloud command-line sessions, package-manager tokens, deployment keys, SSH identities, and local environment references; each should be mapped to the systems that could be reached from that host.

What the incident changes about marketplace governance

The Cursor incident places marketplace trust, package provenance, signing, and key rotation inside normal software-supply-chain governance. AI coding extensions can inspect development context, execute local code, access files, and influence network activity, so procurement and security controls should reflect that privilege.

Package provenance means being able to establish where software came from, which publisher produced it, and how its contents moved through distribution. A marketplace listing alone is not a complete provenance record for enterprise use.

Code signing uses a cryptographic signature to help verify that software came from an expected publisher and was not altered after signing. Leaders should ask whether signatures are verified at installation and update time, how signing keys are protected, and how quickly trust is revoked when a key or package is questioned.

Marketplace governance should also define who can approve extensions, which versions are allowed, how emergency blocks work, and how installation evidence is retained. A central allowlist can reduce unreviewed software, but it must be paired with update review so an approved extension cannot become a permanently trusted blind spot.

Developer-machine isolation is another control question, not a claim about what happened in this incident. Teams should decide whether AI coding extensions need access to production credentials, sensitive repositories, private package registries, or broad home-directory data, and then reduce access where the workflow does not require it.

Egress controls are rules that restrict or monitor outbound network connections. Security architects should assess whether developer machines can make unexpected SSH connections, whether outbound destinations are logged, and whether AI extensions can reach systems unrelated to their approved workflow.

These controls also answer the related enterprise question of which AI code tool offers the best administrative controls. There is no defensible universal winner from this incident alone; the practical comparison is whether each tool supports verifiable provenance, version control, permission boundaries, endpoint visibility, network policy, rapid revocation, and clear incident ownership.

Security, platform engineering, and procurement should each receive a named decision. Security should define the threat and response requirements. Platform engineering should implement inventory, isolation, telemetry, and approved installation paths. Procurement should require evidence about publisher identity, signing, update controls, key rotation, and incident notification before treating an AI extension as standard enterprise software.

What AI adoption leaders should decide next

AI adoption leaders should classify coding extensions as privileged software and assign ownership for exposure review, approval, monitoring, and response. The Cursor marketplace incident is a governance test for every organisation adopting AI-assisted development.

The immediate decisions are straightforward: identify potentially exposed machines, preserve evidence, remove unauthorized persistence, assess credential and session rotation, and document rebuild criteria. The longer-term decision is whether the organisation can observe and control extensions with the same discipline applied to other software that runs inside privileged development environments.

WAO GPT publishes independent business analyses and AI breakdowns for leaders making decisions about automation, agents, infrastructure, and enterprise architecture. Subscribe or register to receive WAO GPT’s business analyses, AI breakdowns, and editorial briefings.

Frequently asked questions

Was the malicious Claude Code extension developed by Anthropic?

No. Cursor reported that the malicious versions were not developed by Anthropic. The modified package was made available through the Cursor VS Code Extension Marketplace.

Which Claude Code extension versions were reported as malicious?

Cursor identified versions 2.1.312 and 2.1.313 for Windows and macOS. The reported exposure window was approximately 2:27 AM to 1:35 PM Pacific Time on October 29, 2026, or 09:27 to 20:35 UTC.

Were Windows and macOS machines affected?

The reported malicious versions were available for Windows and macOS. A machine using another version or distribution path is not automatically in scope, but enterprise teams should verify local installation and update records.

Is uninstalling the Claude Code extension enough?

Not necessarily. The payload reportedly dropped standalone persistence scripts, so teams should also inspect authorized_keys, SSH settings, LaunchAgents, scheduled tasks, startup scripts, background processes, and relevant network telemetry.

What should an enterprise check after a developer installed the extension?

Review extension version, installation time, operating system, endpoint activity, SSH configuration, persistence mechanisms, outbound connections, and credentials or sessions accessible from the host. The svc-telemetry SSH key label is one source-provided indicator, but its presence or absence does not alone establish the full incident scope.

Last updated: 31 October 2026