A fake Claude extension planted an SSH key. Make every install carry a provenance receipt

THE SIGNAL IN ONE SENTENCE

The dangerous package looked like the useful package. That is the whole trick. Cursor says its extension marketplace served maliciously modified copies of the Anthropic Claude Code extension on October 29. The affected packages were versions 2.1.312 and 2.1.313 for macOS and Windows. They were available from about 2:27 in the morning until 1:35 in the afternoon Pacific time. Anthropic did not build them. Microsoft Security Research says the tampered packages did not come from the Microsoft Visual Studio Marketplace or the official Anthropic package on npm. Microsoft also says Anthropic confirmed that its systems were not compromised. The evidence currently described by Cursor and Microsoft points to the Cursor marketplace path. The malicious code tried to do several things after the extension loaded. It collected host and user information. It attempted to add an attacker-controlled key to the machine's SSH authorization file. It tried to enable the local SSH service, create a reverse tunnel, install startup persistence and report details about the host. Some of the remote-access steps depended on privileges and machine configuration. Cursor says attempts to enable SSH would fail on most macOS and Windows machines because the extension normally lacked administrator rights. That is not the same as saying nothing happened. Cursor says the package still added the attacker's key, installed persistence and sent host details. Microsoft says successful remote access depended on privileges, SSH configuration and the attacker's server, while keys and persistence artifacts could remain even when the tunnel failed. The quiet part is the part worth underlining. Uninstalling the extension may not remove what the extension left behind. Cursor updated its notice on October 30 at 11:30 in the morning Pacific time to correct the affected versions and indicators of compromise. The company now tells affected users to preserve and review evidence, isolate machines showing execution, remove the unauthorized key and persistence, stop tunnel processes, rotate reachable credentials and sessions from a trusted system, and consider whether the host should be rebuilt. This is a software supply-chain incident involving an AI-branded developer tool. It is not evidence that the Claude model designed the attack or that Anthropic distributed the malicious package. It is evidence that a familiar name, package identifier and version number can arrive through a different distribution path carrying different code. Developers need a package provenance receipt. Every extension install and update should leave one behind. The receipt starts with origin. Which marketplace answered the request? Which exact registry endpoint supplied the file? Was a proxy involved? Which publisher identity did the marketplace associate with the package at that moment? Was that identity verified cryptographically, checked through an account badge or merely copied from metadata inside the package? The difference is not decorative. An extension ID can look official while the delivered bytes are not. Next comes the artifact. Record the version, platform, architecture, file size, download time and cryptographic hash. If the package has a valid publisher signature, record the signer and verification result. If it is unsigned, say so in letters large enough to survive a hurried change window. Do not save only the answer that a scanner returned. Save the scanner name, ruleset version, time, submitted hash and result. A green mark without the underlying artifact and scan context becomes folklore the moment threat intelligence changes. The receipt should name the approval path. Was the extension allowed by an enterprise administrator? Was it installed by an individual user? Did an automatic update replace a previously approved version? Did a policy exception allow it? Was there a minimum waiting period between publication and installation? Who can revoke the approval across every machine? Then connect the package to the host. Record which machine received it, which account installed it, whether the editor was running with elevated privileges, which workspaces were open and which credential classes were reachable. Do not copy secrets into the receipt. Inventory the categories: cloud credentials, source-control sessions, signing keys, package tokens, production access, customer data, local SSH configuration and other high-value material. The point is to know what requires rotation without building a second treasure chest for an attacker. This receipt changes incident response from archaeology into filtering. An organization should be able to ask one question and get an exact list: show every machine that received these hashes from this marketplace during this window. Without that record, teams search laptops by memory, ask developers what they clicked and hope a marketplace version number uniquely identifies the bytes. It may not. The response process needs its own completion record. Did the team preserve the suspicious package before removal? Did it inspect extension-installation logs, file changes, process history, network activity, SSH authorization files and startup persistence? Was the machine isolated? Which artifacts were removed? Which credentials and sessions were rotated? Was the machine rebuilt? Who reviewed the evidence and declared recovery complete? The receipt should never declare a machine clean only because one known marker was absent. Microsoft's guidance says a missing marker should not replace review of installation, process, network and persistence evidence. That is a useful general rule. Indicators are clues, not absolution. Cursor says it removed the malicious versions, blocked further distribution, shut down the marketplace as a precaution, audited access, found no other tampered extensions, rotated its keys, rebuilt the marketplace and worked with the hosting provider to take the malicious server offline. Those are meaningful containment actions. They do not answer every longer-term question. How did altered bytes reach the marketplace under a trusted-looking identity? Which control failed? Could the same path have changed an extension without changing its visible version? Which logs let Cursor bound the incident? Will the company publish a root-cause analysis after the investigation? Its current extension documentation describes automated malware and supply-chain analysis, publisher checks, enterprise controls and installation cooldowns. Those layers are useful. The incident is a reminder that no marketplace scan should be treated as a permanent proof of safety. An installation cooldown is especially practical. The newest package is not always the package you need five seconds after release. A short waiting period gives scanners, researchers and other users time to notice a bad artifact before it reaches every developer laptop through automatic updates. That delay is not a universal answer. Emergency security fixes sometimes need speed. The policy can distinguish routine updates from approved urgent patches and record who accepted the risk. Allow lists also need hashes and expiry. Approving the name Anthropic Claude Code forever is weaker than approving a verified publisher, registry, version range and signed artifact for a defined period. The next update should earn a new receipt. The practical application is larger than one editor. Browser extensions, command-line agents, model plug-ins, MCP servers, skills, package-manager hooks and desktop assistants all extend a trusted process with code from somewhere else. Many now act with the user's files, terminal, network and credentials. The security question is not whether the extension is called AI. It is what authority the code receives and whether anyone can prove where that code came from. The human consequence is simple. A developer installing a tool should not have to become a marketplace forensics team before lunch. The platform and employer should preserve the origin evidence automatically, narrow permissions, delay risky updates and provide a tested recovery path. Users still have a job. Install from the expected source. Read urgent notices. Keep editors and extensions current. Treat unexpected authentication prompts, new SSH configuration, strange startup items and outbound tunnels as security events. But the largest burden belongs with the systems that distribute, approve and update executable code. Trust is not a package name. It is a chain of evidence from publisher to registry to artifact to approval to host. Print that chain on the receipt.