Malicious Claude Code Extension Appears in Cursor Marketplace: An 11-Hour Supply Chain Attack

AI coding tools are becoming a new target for attackers, and this time the problem lies in the very link developers trust most—the official plugin marketplace.

A Supply Chain Attack That Breached No Servers

According to disclosures from a YouTube tech channel, a tampered version of Anthropic's official Claude Code extension quietly survived in the Cursor code editor marketplace for a full 11 hours. Developers downloaded what appeared to be a verified tool, but were actually pulling malicious code that led straight into their local secure workspaces.

The most counterintuitive part of this incident is that neither Anthropic's nor Microsoft's official systems were touched throughout. The attackers did not breach the infrastructure of any multibillion-dollar vendor; they merely poisoned a distribution channel that developers blindly trust. The low cost and high stealth of this path warrant a re-examination of one's trust model by anyone using AI coding tools.

A supply chain attack refers to an attack in which adversaries do not directly target the end goal but instead compromise third-party components, tools, or distribution channels that the target relies on, leveraging trusted relationships to deliver malicious code "along the way" into victim environments. Typical links in the software supply chain include code repositories, build systems, package managers (such as npm and PyPI), plugin marketplaces, and auto-update mechanisms. The core logic of such attacks is "trust transitivity": developers trust the upstream vendor, and therefore also trust artifacts distributed by that vendor. Well-known recent cases include the SolarWinds incident, the tampering of CodeCov scripts, and malicious npm package poisoning. Compared with direct intrusion, supply chain attacks are cheaper, cover a broader surface, and are often difficult to trace to their source during forensics. The plugin marketplace poisoning described in this article falls into the subcategory of tampered distribution channels.

What the Malicious Payload Did

Once inside the development environment, the hidden payload aggressively collected device information and attempted to plant a "digital master key"—an SSH backdoor—to gain permanent access. SSH is the core channel through which developers connect to remote servers, code repositories, and production environments. A planted SSH backdoor means attackers can bypass passwords and conventional authentication and lie dormant in a developer's infrastructure for the long term.

The intent behind this attack design is clear: not one-off theft, but the establishment of a persistent foothold. For developers with production environment access, this is far more dangerous than a simple data leak.

SSH (Secure Shell) is an encrypted network protocol used to securely log in to servers remotely, execute commands, and transfer files over insecure networks. Developers typically authenticate using SSH key pairs (public/private keys) rather than passwords: the public key is stored in the target server's ~/.ssh/authorized_keys file, while the private key remains local. Once an attacker can append their own public key to authorized_keys, they can log in to that server permanently without a password—the so-called "SSH backdoor." Because SSH is the standard channel for connecting code repositories, jump hosts, and production environments, a successfully implanted SSH backdoor allows attackers to bypass conventional authentication and auditing, lie dormant for the long term, and move laterally. Key methods for detecting SSH backdoors include regularly auditing authorized_keys, monitoring sshd login logs, and using file integrity monitoring tools.

The Permission Wall Stopped the Most Dangerous Step

The attack hit a wall at a critical point. Locking in the SSH backdoor required administrator privileges, so on the vast majority of machines, the most dangerous step quietly failed. This is a classic case of "defense in depth" working—even though the malicious code broke through the outer line of marketplace review, the operating system's permission model still formed a second barrier.

But relying on a single protective layer to get lucky is not a reason to rest easy. Development environments with looser permission configurations, or users accustomed to running tools with high privileges, would face a completely different situation.

Defense in depth is a security architecture principle that involves deploying multiple independent layers of security controls in a system so that if a single line of defense is breached, subsequent lines can still stop or mitigate the attack. Typical layers include network security, application-layer validation, identity authentication, the operating system permission model, and audit logs. In this article, plugin marketplace review can be seen as the outer line of defense, while the operating system's administrator privilege requirement constitutes the second barrier—modifying system-level SSH configurations usually requires root or Administrator privileges, and a process running under ordinary user permissions cannot accomplish this. The value of defense in depth lies in the fact that it does not assume any single link is absolutely reliable. Note, however, that multiple layers of defense are effective only when each layer is truly independent and properly configured; if developers habitually run tools with high privileges, the permission wall layer becomes virtually nonexistent.

The Attacker's Server Is Down, but the Malicious Files Remain

The attacker's server is now offline, but that is not the end of the story. Among as many as 5,000 exposed users, malicious files remain embedded in their systems until manually cleaned up. This means the risk window does not automatically close when the attack infrastructure is shut down.

For affected users, uninstalling the extension does not equal a clean removal—they need to proactively check for remnants in the local file system and inspect SSH configurations for anomalous authorized entries. The threshold for such manual cleanup is precisely the difficulty of post-incident remediation for supply chain attacks.

Why Marketplace Review Mechanisms Failed Collectively

The 11-hour survival time exposes more than just a review gap on a single platform. The Cursor marketplace, the extension verification badge, and developers' default trust in the word "official"—the three combined to create a perfect attack surface. Attackers did not need a technical knockout; they only needed to find a time gap in the review chain.

For developers, actionable defense strategies include: reviewing an extension's publisher identity and update history, running AI coding tools in permission-restricted environments, and regularly checking sensitive configurations such as SSH authorized_keys. For platforms, integrity verification and publisher identity binding in the extension update process clearly require stronger guarantees than "looks verified."

What makes supply chain attacks frightening has never been technical complexity, but the fact that they strike precisely at trust itself. As AI coding assistants increasingly connect deeply to local environments and production infrastructure, the security level of plugin marketplaces is now directly equivalent to the security level of developers.

The extension verification badge (such as a "verified publisher" badge) usually indicates that the platform has verified the publisher's identity or domain ownership, but it does not guarantee that the content of every update to the extension has undergone security review, nor that the publisher's account has not been compromised. Many marketplaces concentrate review on the initial listing stage, using automated or spot-check validation for subsequent version updates, which leaves a "time gap" attack window: attackers can first publish a clean version that passes review, then push an update containing malicious code. Stricter practices include performing integrity verification on every update (such as signature verification), binding publisher identity to signing keys, and conducting differential review of update content. For developers, "verified" should be treated as an identity clue rather than a security guarantee, and should be combined with the publisher's history, update frequency, and scope of permission requests for a comprehensive judgment.

One-line Summary

A tampered Claude Code extension survived 11 hours in the Cursor marketplace, exposing trust gaps in the plugin marketplace supply chain.

Paragraph Summary

The article discloses a supply chain attack targeting AI coding tools: a tampered version of Anthropic's official Claude Code extension quietly survived for 11 hours in the Cursor code editor marketplace. The attackers did not breach any Anthropic or Microsoft servers; instead, they poisoned a distribution channel trusted by developers. The malicious payload collected device information and attempted to implant an SSH backdoor for permanent access, but because modifying SSH configurations required administrator privileges, the most dangerous step failed on most machines. Although the attacker's server is now offline, malicious files remain on the systems of up to 5,000 exposed users and must be manually cleaned. The incident reveals a structural security gap formed by the combination of marketplace review, extension verification badges, and developers' default trust.