Deleting the Extension Isn't Enough? A Post-Mortem of the Poisoned Claude Code Extension Incident

According to a supply chain security incident disclosed by a YouTube channel, two versions of the Claude Code extension were implanted with malicious code within the Cursor editor, released on October 29 and remaining online for approximately 11 hours. One developer clicked update before heading out for lunch, and upon returning found her computer opening windows on its own, scrolling through files, and even quietly planting a new SSH key in a list. More unsettling still: even after she deleted the extension and the screen seemed to settle back to normal, another window popped up in the corner—Cursor's official warning, with wording and intent both unambiguous: uninstalling the extension may not be enough.

Incident Recap: An 11-Hour Poisoning Window

According to the video description, the compromised builds were distributed through normal update channels, running as the Claude Code extension within Cursor. From release to detection, the window was about 11 hours. Cursor's own statistics state that the affected builds may have reached as many as 5,000 developers, but the video explicitly notes that no one knows the real number. This uncertainty is itself a hallmark of supply chain attacks: you cannot obtain an exact exposure scope from official channels.

The attacker's operations were not crude destruction but left detectable anomalous behavior: windows popping up on their own, files scrolling automatically, and most critically—an unauthorized SSH key written into the system. An SSH key means persistent remote access, which is typically the first step an attacker takes to establish a backdoor.

Supply Chain Attack refers to an attacker not directly targeting the end victim, but rather compromising a trusted upstream link—such as software distribution channels, build systems, dependency repositories, or update servers—delivering malicious code to victims through the legitimate distribution path. Such attacks are dangerous because they bypass the conventional security assumption of "I downloaded it from an official channel." SolarWinds, Codecov, and multiple incidents in the npm ecosystem all fall into this category. In this case, the compromised builds were pushed through Cursor's normal update mechanism; developers clicking "update" would not expect risk, which is why the detection window was extremely short and the exposure scope difficult to define.

After Deleting the Extension, Why Does the Risk Remain?

The most alarming detail in the video: after the developer deleted the extension, the screen was briefly quiet, and then a small window opened on its own. This echoes the core of Cursor's official warning—uninstalling the extension may not be sufficient to remove the threat. The reason is that malicious code may have already completed persistence operations during execution, such as writing SSH keys, modifying system configurations, or implanting other startup items. The extension itself is merely an entry point; once the malicious logic is executed, its impact extends beyond the extension directory.

This explains why the official recommendation is either to completely wipe the entire machine or at minimum to perform five checks. The video does not list the specific contents of these five checks one by one, but clearly conveys the handling principle: do not assume the risk is resolved just because the interface looks clean again.

Persistence is the collective term for techniques attackers use to maintain access after an initial compromise. Common methods include writing SSH public keys to ~/.ssh/authorized_keys, creating system services or scheduled tasks, modifying shell startup scripts, and implanting browser extensions or login items. The goal is to enable the attacker to retain remote control of the target machine even after the original entry point (such as a deleted extension) is gone. In this case, the unauthorized SSH key is a textbook persistence operation: as long as the key is not removed, the attacker can log back in at any time via the SSH protocol, regardless of whether the extension is still present. This is the technical root of the official warning that "uninstalling may not be enough"—removing the entry point does not equal removing all traces.

SSH key authentication is one of the most common methods for remote server login. The client holds the private key, and the server stores the corresponding public key in ~/.ssh/authorized_keys; a match allows passwordless login. For an attacker, writing their own public key to the target machine is equivalent to opening a long-term backdoor: no password required, unlikely to trigger alerts, and able to survive reboots. Developers should regularly audit the authorized_keys file for unknown entries; if suspicious keys are found, they should be deleted immediately, all related credentials rotated, and depending on the situation, the system reinstalled—because the malicious process that wrote the key may have left other undiscovered persistence mechanisms.

Practical Takeaways for Developers

This incident is not an isolated case, but it brings a structural problem in the AI coding tool ecosystem into the open: developers' trust in editor extensions is often built on two assumptions—the "official marketplace" and "automatic updates." When the update channel itself is compromised, both assumptions fail simultaneously. For developers who routinely use tools like Cursor and Claude Code, the video's message is direct: when encountering similar anomalous behavior, do not stop at uninstalling the extension; if you cannot confirm whether persistence traces have been removed, reinstalling the system is the safer choice.

The cost of supply chain security is never just technical cost—it is also attention cost. A lunch break's time difference is enough for a seemingly clean machine to continue working for an attacker.