Originally published at ReclaimLLM.

Cursor's notice on tampered Anthropic.claude-code 2.1.312 and 2.1.313: who was exposed, how to check a machine, and extension controls to add.

The tampered Claude Code extension in Cursor's marketplace: what teams should check

Updated November 14, 2026.

On October 29, 2026, tampered copies of Anthropic's Claude Code extension were served from Cursor's VS Code extension marketplace for about 11 hours. Cursor's security notice provides indicators of compromise and cleanup scripts; its fuller incident update is dated November 13.

This post summarizes what the official sources say, how a team can check its machines, and which extension controls to add. Everything about the malware comes from Cursor's notice and two independent analyses. Where the sources do not say something, we do not guess.

What happened

Affected artifact. Anthropic.claude-code versions 2.1.312 and 2.1.313 for Windows and macOS, installed or updated from the Cursor VS Code Extension Marketplace (Cursor security notice).

Exposure window. About 2:27 a.m. to 1:35 p.m. Pacific Time on October 29, 2026 (about 5:27 a.m. to 4:35 p.m. in Toronto) (Cursor security notice).

Who published it. Not Anthropic. Cursor's update says an attacker used a credential stolen from Cursor's internal systems to place the tampered copies directly on the cache that serves Cursor's extension marketplace. Cursor says this was not a vulnerability in Anthropic's product, and that Open VSX, the marketplace source, never had the malware (Cursor incident update). Microsoft reports that the malicious packages were never published on the Visual Studio Marketplace or in the npm package @anthropic-ai/claude-code (Microsoft Security Blog). StepSecurity reports that Anthropic confirmed 2.1.313 was never published on any official channel and skipped to 2.1.314 to avoid confusion (StepSecurity).

How many people. Cursor says at most 5,000 users who requested specific cached versions on October 29 potentially received the malicious build, and that it contacted affected customers directly (Cursor incident update).

How it started. Cursor's update traces the attack to an access key Cursor had issued to Fireworks, an inference vendor. The key was exposed at Fireworks, and the attacker used it to copy data from a storage bucket Cursor shared with Fireworks. That data included some credentials, which the attacker used to reach other Cursor systems (Cursor incident update; Fireworks security bulletins).

What was not affected, according to Cursor: other extensions in the marketplace, plugins from the Cursor Marketplace, the Cursor app and its official updates, customer code repositories, and prompts and code of users in Privacy Mode (Cursor incident update).

What the malicious code did

Cursor's notice says the tampered extension:

  • Collected host and user details: hostname, username, OS, architecture, home directory path, environment variable names, working directories, configured Git email and public IP.
  • Tried to add an attacker-controlled SSH key (comment svc-telemetry) to authorized_keys, enable the local SSH service, and open a reverse SSH tunnel.
  • Tried to persist through a LaunchAgent on macOS, or a scheduled task with a Startup-folder fallback on Windows.

Cursor also says that turning on the SSH service needs admin rights, which the extension does not have on most macOS and Windows hosts, so on those hosts the tunnel step failed. But the extension still added the key, installed persistence and sent host details. The attacker's server has been taken offline (Cursor security notice).

Microsoft's analysis adds two useful details. The loader sends environment variable names, not values. And the code runs when the extension module loads, so no Claude conversation is needed (Microsoft Security Blog). StepSecurity's analysis agrees that loading the module is enough (StepSecurity).

Step 1: find out if any machine was exposed

A version number alone does not prove compromise. StepSecurity notes that the 2.1.312 build on Open VSX is a different, clean file. What matters is the source (Cursor's marketplace), the platform (macOS or Windows) and the time (the October 29 window).

List exposed machines. Use your endpoint or extension-installation telemetry to find Cursor installs that installed or auto-updated Anthropic.claude-code to 2.1.312 or 2.1.313 during the window. Check whether Cursor or your team admins received a notice from Cursor.

Check each candidate machine for the SSH key. Cursor's notice gives a one-line check for macOS and a PowerShell check for Windows. Both look for svc-telemetry in the authorized keys files. Copy the commands from the notice, not from a third-party page.

Hunt for the published indicators. A missing SSH marker alone does not rule out exposure; correlate installation records, process activity and persistence artifacts. The notice lists file hashes, the attacker IP, persistence file paths, the scheduled task name and the SSH command line. Microsoft publishes Defender hunting queries for the same indicators.

Step 2: investigate and clean up affected machines

Cursor's notice gives these steps for affected hosts (Cursor security notice):

  • Isolate hosts that show signs of payload execution or backdoor installation.
  • Remove the unauthorized SSH key, persistence and running tunnel processes. Cursor provides remediate-macos.sh (run as the affected user, not root) and remediate-windows.ps1 (run as Administrator). Assess whether the host should be rebuilt.
  • Do not rely on uninstalling the extension. The payload drops standalone scripts outside the extension folder that keep running.
  • Rotate credentials and sessions reachable from affected hosts, from a trusted system. Cursor says the limited environment-variable collection does not rule out later credential access over the backdoor.

Microsoft adds: preserve evidence (the extension package, modified SSH files, scripts and startup entries) before cleanup, and keep unrelated SSH keys and legitimate remote-development settings (Microsoft Security Blog).

Questions go to security@cursor.com, the contact both Cursor posts give.

Step 3: add extension controls for next time

Users in the Cursor forum asked whether they can trust plugin updates (t/176923). Trust is a policy question. These controls reduce how much you depend on it.

  • Allow only approved publishers. Cursor's security-hardening guide lists Allowed Extensions, an allowlist of trusted publishers. Note that the tampered copy here used Anthropic's real extension ID, so a publisher allowlist alone would not have stopped it (Cursor security hardening).
  • Set an install cooldown. The same guide describes an extension install cooldown that defers installs and updates until a version has been public for a set number of hours, enforced fleet-wide, "to blunt short-lived malicious uploads". Microsoft recommends the same control. This exposure lasted about 11 hours, so the cooldown length matters.
  • Turn on signature verification where available. Cursor's guide lists it as an optional part of the cooldown setting.
  • Know where each extension came from. Record the marketplace source for your editor fleet. A version number is not enough to tell a clean build from a tampered one.
  • Keep extension and MCP reviews separate. An editor extension, a plugin and an MCP server are different install paths with different controls. Our MCP security guide covers MCP servers.
  • Limit what a compromised editor can reach. Short-lived credentials, no production secrets in shell environment variables, and SSH server disabled on laptops that do not need it all reduce the damage of any malicious extension.

Cursor documents these controls in its enterprise hardening guidance. Check the linked configuration pages for your client version and deployment method; do not assume every plan supports the same fleet-wide enforcement.

Where ReclaimLLM fits

Use endpoint and extension-installation telemetry to investigate this incident. A captured AI session is not evidence that an extension was installed, and this article makes no claim that ReclaimLLM detected or blocked the tampered package.

What it does: it captures AI coding sessions from Cursor, Claude Code, Copilot, Codex and Antigravity through hooks, and makes them searchable. After an incident like this, that record can help answer a narrower question: during the exposure window, which sensitive values appeared in the captured agent sessions on an affected machine. That is supplementary evidence: it cannot establish every credential the compromised host could access or narrow the vendor's rotation guidance. Detection of secrets and external egress in captured sessions runs on an hourly or daily sweep and raises alerts; it does not block.

For the broader agent setup, see our Claude Code security guide.

FAQ

Was Anthropic hacked?

Cursor says no: Anthropic did not publish the tampered copy, and it was not a vulnerability in Anthropic's product (Cursor incident update). Microsoft says Anthropic confirmed its systems were not compromised.

I use Claude Code in VS Code, not Cursor. Am I affected?

According to Cursor, Microsoft and StepSecurity, the tampered builds were only served from Cursor's marketplace. The Visual Studio Marketplace, Open VSX and the npm package were not affected.

Is Linux affected?

Cursor's notice names Windows and macOS builds. The indicator list also includes Linux file paths for the persistence scripts. Those artifacts do not establish that a malicious Linux package was distributed. If your Linux telemetry shows matching indicators, investigate them under your incident-response process.

Does uninstalling the extension fix it?

Not by itself. The payload installs scripts outside the extension folder. Follow Cursor's cleanup steps.

Review your Cursor extension security.

Read the original article at ReclaimLLM.