Breaking
SecurityDeveloping Story

Cursor Marketplace Breach Hits Developer SSH

Malicious Claude Code extension in Cursor's marketplace attempted to plant an SSH backdoor, exposing supply chain risks for developers.

··2 hours ago·8 min read
two gray padlock on pink surface
Photo by FlyD on Unsplash

Developers who installed what looked like a routine update from the Cursor VS Code Extension Marketplace may have received more than they bargained for. For roughly 11 hours on October 29, a tampered version of Anthropic's Claude Code extension was available for download, and it carried code designed to slip an attacker-controlled SSH key onto the user's machine.

Cursor disclosed the incident in a security notice, stating that the malicious package was live from about 2:27am PT to 1:35pm PT. The company pulled the affected versions—2.1.312 and 2.1.313—after discovering the problem, but not before the code had the chance to run on Windows and macOS systems.

How the tampered extension was planted

According to Cursor, the modified extension attempted to add an attacker-controlled SSH key, enable local SSH access, and establish a reverse tunnel to a server controlled by the attacker. Cursor emphasized that “These malicious versions of the extension were not developed by Anthropic,” distancing the AI vendor from the compromised build.

Anthropic later clarified that its own infrastructure was not breached. In a post on X, Felix Rieseberg, a member of Anthropic's technical staff, said the incident did not involve a compromise of Anthropic's systems or employee laptops. A malicious actor had used access to Cursor's marketplace to publish the modified extension, he said. “The versions on our official channels are not affected, and this only impacts Cursor users,” Rieseberg wrote. Anthropic said it was working with Cursor on the incident.

Cursor and Anthropic had not responded to requests for comment by publication time. The source article notes that the malicious code was inserted at the beginning of the extension's JavaScript file, a detail that matters for understanding how the attack unfolded.

No clicks required for infection

Security company Phorion analyzed the compromised extension and found that the malicious code ran as soon as the extension loaded, before any normal activation code. “The user doesn't need to interact with the extension for the payload to fire,” Phorion said. That means simply having the extension installed and loading it was enough to trigger the payload.

Once active, the malware attempted to add an attacker-controlled SSH key to the user's authorized_keys file and establish a connection to a remote server. Phorion added that it also created scripts and startup entries intended to keep the connection available after a system restart. In other words, the goal was persistence—a backdoor that would survive reboots and remain available for later access.

Phorion identified a flaw in the macOS code that likely prevented the SSH enablement from succeeding. The malware tried to check whether Remote Login was disabled using a system command that required administrator privileges. When run without those privileges, the command returned an access error rather than the expected status, and the malware consequently skipped the attempt to enable SSH. Phorion also found an error in the Windows code that could prevent its SSH service setup command from running correctly.

Microsoft Threat Intelligence, in a separate analysis, detailed the information the malware collected, including machine names, usernames, operating systems, working directories, and Git email addresses. “It also looks for environment-variable names containing terms such as KEY, TOKEN, SECRET, PASS, AWS, or GCP, keeping up to forty matches,” Microsoft wrote in the analysis. It said the code collected matching variable names, not their values.

Cleanup goes beyond uninstalling

Cursor said enabling the local SSH service would generally fail without administrator privileges on affected Windows and macOS machines. However, the extension could still add the attacker's SSH key, install persistence mechanisms, and send host information to the attacker. The company warned that uninstalling the extension alone might not remove these components because the malware placed scripts outside the extension's installation directory.

Steve Povolny, vice president of AI strategy and security research at Exabeam, said the planted SSH key made cleanup particularly important. “Removing the extension only sends the visitor away while the spare key stays on the hook,” he said. Povolny recommended checking authorized SSH keys on machines accessible to affected developers, rotating potentially exposed credentials, and reviewing logs for logins using unfamiliar keys.

He noted that developers often have access to source code, cloud accounts, and production systems, making a compromised workstation a potential route to other enterprise resources. Phorion also advised checking the SSH key's fingerprint rather than relying only on the comment svc-telemetry attached to it.

A gap in marketplace trust

Yash Kadakia, founder and CTO of Security Brigade, said enterprises should treat extension marketplaces as part of the software supply chain. “An extension marketplace is effectively another software supply chain,” Kadakia said. “When malicious code can reach developers through what appears to be a legitimate, routine update, the traditional assumption that software from a trusted marketplace is safe starts to break down.”

He recommended stronger publisher verification, checks on package integrity, and controls over which extensions and versions developers can install. Kadakia also called for extension allowlisting, controlled updates, endpoint monitoring, and restrictions on outbound connections. He said short-lived credentials, segregated development environments, and limited access to sensitive infrastructure could reduce the impact of a compromised developer machine.

Cursor said it removed the malicious versions, temporarily shut down its marketplace, audited access, rotated keys, and rebuilt the marketplace before restoring the service. The company's response included multiple steps aimed at containing the damage and preventing similar incidents.

What the malware tried to do

The attack chain, as described by Phorion and Microsoft, involved several stages. First, the malicious code executed on extension load. Then it attempted to modify the authorized_keys file—a common mechanism for granting SSH access—and establish a reverse tunnel. It also created scripts and startup entries for persistence. Finally, it collected host information and scanned environment variable names for sensitive terms.

The fact that the malware looked for variable names like KEY, TOKEN, SECRET, PASS, AWS, or GCP suggests it was hunting for clues about cloud credentials and other secrets, even though it did not capture the values themselves. That information could still be valuable for planning further attacks or for social engineering.

Why the macOS and Windows flaws matter

The flaws Phorion found in the macOS and Windows code may have limited the attack's success, but they don't eliminate the risk. On macOS, the malware's attempt to enable SSH failed because it required administrator privileges that weren't available. On Windows, an error could prevent the SSH service setup command from running correctly. However, the core payload—adding an SSH key and establishing persistence—could still succeed even if the SSH service itself wasn't enabled.

That distinction is important for anyone assessing exposure. Even if the reverse tunnel didn't work, the attacker's key could remain in the authorized_keys file, providing a way back in later. Similarly, the persistence scripts could keep the connection alive after a reboot, depending on how they were configured.

What developers and enterprises should watch for

For developers who may have installed the affected versions, the immediate steps are clear: check for unauthorized SSH keys, rotate credentials that may have been exposed, and review logs for logins using unfamiliar keys. Povolny's advice to check the key's fingerprint rather than the comment is particularly relevant because the comment svc-telemetry could be used to disguise the key's origin.

Enterprises should consider broader controls. Kadakia's recommendations include publisher verification, package integrity checks, extension allowlisting, controlled updates, endpoint monitoring, and restrictions on outbound connections. These measures aim to reduce the likelihood of a similar compromise and to limit the damage if one occurs.

Cursor's own response—removing the versions, shutting down the marketplace, auditing access, rotating keys, and rebuilding—provides a template for how a marketplace operator might respond to a supply chain incident. But the incident also raises questions about how extensions are vetted before they become available.

The bigger picture for software supply chains

This incident is a reminder that extension marketplaces are part of the software supply chain, and they can be a vector for attacks that bypass traditional security assumptions. When developers install extensions from a marketplace, they are trusting the marketplace to ensure that the code is legitimate and unmodified. In this case, that trust was misplaced.

The fact that the malicious code ran without user interaction makes it particularly dangerous. Developers may have installed the extension and never noticed anything unusual until the SSH key was used or the persistence mechanism was discovered. The 11-hour window during which the malicious versions were available means that any developer who updated during that time could have been affected.

Anthropic's clarification that its own channels were not affected is important for its users, but it doesn't diminish the risk for Cursor users. The incident highlights the need for stronger controls around who can publish to marketplaces and how quickly malicious updates can be detected and removed.

What this means for the industry

The Cursor incident suggests that extension marketplaces may need to adopt stricter verification and monitoring practices. If a malicious actor can publish a modified version of a popular extension, even for a short time, the potential for damage is significant. The response from Cursor—shutting down the marketplace and rebuilding—shows that operators can take decisive action, but the incident also points to the importance of preventing such compromises in the first place.

For enterprises, the lesson is to treat developer workstations as high-value targets and to apply the same rigor to extension management as to other software. Allowlisting, version pinning, and network restrictions can help, but they require ongoing attention. The alternative—relying on the assumption that marketplace software is safe—is increasingly untenable.

As AI coding assistants become more common, the attack surface for similar incidents may grow. The Cursor case is a concrete example of how a trusted update mechanism can be turned against users. The details of this incident, from the 11-hour window to the specific versions and the cleanup challenges, provide a case study for security teams evaluating their own exposure.

#supply chain#ssh backdoor#cursor#claude code#extension security

Sources

Iliyas

Founder & Editor, Xploitwire

This article was written and reviewed against the sources listed above before publication, under editorial policies set by Iliyas. Read our Editorial Policy →

← Back to all stories