Cursor Supply Chain Attack: How a Single Key Compromised 5,000 Developers

AI coding tool Cursor has just concluded a two-week investigation, disclosing a supply chain attack that has unsettled the developer community. According to the YouTube tech channel Deccan Tech, attackers exploited a leaked AI vendor access key to turn Cursor into a backdoor entry point for roughly 5,000 developers. The details of this incident deserve a careful read from every developer using AI coding tools.

The Full Picture: From Leaked Key to Malicious Extension Listing

According to Deccan Tech's account, the attack chain did not begin with a direct vulnerability in Cursor's own systems, but rather with a third-party link. Attackers obtained an access key that Cursor had issued to its AI vendor, Fireworks.

The role of this key should not be underestimated—it unlocked a shared storage bucket containing historical coding agent traces. In other words, the compromise of a single vendor credential gave attackers access to a corner of Cursor's internal data.

The real climax occurred on October 29. Attackers inserted poisoned copies of the Anthropic Claude code extension into Cursor's marketplace cache. These counterfeit versions concealed an SSH backdoor and were only addressed about 11 hours after being listed, during which time they may have reached approximately 5,000 users.

The Trust Model of Access Keys and Shared Storage Buckets

In the collaborative architecture of AI coding tools, software vendors typically issue access keys to service providers such as AI model vendors for calling APIs or reading and writing shared resources. These keys are often bound to a set of resources beyond the minimum necessary permissions—for example, shared storage buckets used for debugging and auditing. Once a key leaks, attackers can access protected data with legitimate credentials without directly breaching the main system. This explains why the starting point of this incident was a vendor credential rather than a vulnerability in Cursor itself: the trust boundary was extended to third parties, and any lax credential management on any side becomes the weakest link in the entire chain.

Accountability: Anthropic Denies Publishing, Fireworks Cut Off

One key fact needs to be clarified: Cursor explicitly stated that these malicious extensions were not officially published by Anthropic. Attackers merely borrowed the name and appearance of the Claude extension, disguising the backdoor as a tool familiar to developers.

This means the risk did not originate from Anthropic itself, but rather from a gap in trust verification at the marketplace cache layer.

Cursor's response included blocking further attack attempts on November 1 and severing its connection with Fireworks. From the timeline, the entire process from the malicious extension being listed on October 29 to the attack being intercepted on November 1 spanned less than a week, but the investigation lasted a full two weeks.

The Real Threat to Developers: Uninstalling May Not Be Enough

The most alarming aspect of this incident is a warning Deccan Tech specifically emphasized in its video: simply uninstalling the extension may not fully clean an affected machine.

The nature of an SSH backdoor means it can persist in the system even after the extension is removed. For Cursor users who installed or updated the Claude code extension during that roughly 11-hour window, the checks required go far beyond the extension management panel.

The direct advice given in the video is: immediately verify the version of the extension you are currently using. This advice seems simple, but given the short lifespan and wide reach of the malicious version, proactive verification is more reliable than passively waiting for notification.

Why SSH Backdoors Can Bypass Routine Uninstallation

An SSH backdoor is typically not a file within the extension package, but rather something written into system-level configuration when the extension runs. For example, it may modify ~/.ssh/authorized_keys in the user's home directory, inject startup scripts, or register persistent services, thereby maintaining remote access capability even after the extension is deleted. Such persistence mechanisms are independent of the extension itself, so uninstalling through the extension management panel only removes the entry point and cannot reclaim credentials or services already written into the system. Affected users need to check SSH authorization files, startup items, and anomalous network connections, and if necessary, regenerate key pairs and rotate credentials to thoroughly eliminate the risk.

A Few Calm Observations

What this incident exposes is not a single point of failure at Cursor, but rather an easily overlooked trust chain in the AI coding tool ecosystem: tool vendors, AI model vendors, extension marketplaces, and caching mechanisms—improper credential management at any link can be amplified into a security risk for end users.

The attackers' choice of the Claude extension as a disguise is also telling—the more developers trust and frequently use a tool in their daily work, the easier it is to overlook anomalies during version updates. For heavy users of AI coding tools, this incident provides a concrete behavioral reminder: verifying extension sources and version numbers should become routine practice rather than after-the-fact remediation.

Cursor's investigation has concluded, but the discussion around vendor key management and marketplace cache verification mechanisms is likely just beginning.

The Role and Limitations of Marketplace Cache Verification Mechanisms

Extension marketplaces typically cache extension packages locally or at edge nodes to accelerate distribution and reduce origin server load. However, if the cache layer lacks continuous verification of package signatures, publisher identity, and version hashes, it can be exploited by attackers to mix counterfeit versions into the cache and distribute them to users. The ideal approach is to verify the extension's digital signature and consistency with the official source on every install or update, and to set time limits and integrity checks on cached content. This incident shows that caching is not only a performance component but also part of the security boundary—its verification strength directly determines whether a supply chain attack can succeed.