On October 29, 2026, an unusual and alarming event shook the developer community: a malicious version of the official Claude Code extension, published to Cursor's extension marketplace, was available for installation for approximately eleven hours, infecting up to 5,000 users. The attack did not exploit a vulnerability in the Claude Code code itself — the original extension was simply replaced with a trojanized version that, when installed, planted an attacker-controlled SSH key into the authorized_keys file, attempted to enable the local SSH service, and opened a reverse tunnel to a remote server.
What makes this incident particularly significant goes beyond the technical sophistication of the attack. It illustrates a structural shift in the cyber threat landscape: developers using AI-powered coding tools are becoming direct targets of supply-chain attacks, and a single malicious plugin can deliver root access to an entire development environment. The malicious extension, in versions 2.1.312 and 2.1.313, executed malicious code before the extension's activate callback was even called — the injected code was prepended to the extension module's extension.js, running automatically whenever the IDE or Cursor started.
The attack chain
The trojanized extension contained a 66-line loader that was prepended to the original extension bundle. When the extension loaded, the loader executed immediately, without any user interaction, and executed a four-stage action chain.
Stage one prepared SSH access. The malware ensured the ~/.ssh directory existed and appended an Ed25519 public key with the comment `svc-telemetry` to the user's authorized_keys file. It simultaneously attempted to enable the local SSH service — via `systemsetup -setremotelogin on` on macOS, systemctl on Linux, and the OpenSSH server on Windows. It then initiated a continuous reverse SSH tunnel to IP 134.209.82.225 on port 8099, using a retry loop every 60 seconds with `autossh`, falling back to `ssh` if autossh failed. The connection used `-N -R '*:0:localhost:22'` with host verification disabled (`StrictHostKeyChecking=no`).
Stage two was persistence. The malware installed boot-level mechanisms on each platform: on macOS, a malicious LaunchAgent called `com.apple.sysmond.plist` — intentionally named to look like a legitimate Apple service — stored in ~/Library/LaunchAgents/; on Linux, a user crontab entry `@reboot` executing ~/.config/.smt; on Windows, a scheduled task called SysMon accessible via `schtasks`, with a fallback to a Startup folder script. The loader also wrote a PEM-format private key to a hidden file ~/.config/.smtk and to a temporary file matching the pattern $TMPDIR/.stk_*, creating the credentials that sustained both the tunnel and the planted SSH key.
Stage three was the beacon. The malware sent host data to the attacker's server via plain HTTP (no TLS) on the /beacon path — an interesting decision that facilitates network traffic detection. The data included hostname, username, operating system, architecture, home directory path, current working directory, configured Git email, public IP address, and, notably, the names of environment variables matching patterns like KEY, TOKEN, SECRET, PASS, AWS, or GCP. The beacon sent up to 40 variable names per POST, but not the values — which does not mean the values were safe, but rather that the attacker was first mapping which credentials were available in the environment before attempting to access them via the backdoor.
Stage four was additional context exfiltration. The malware collected working directory names, allowing the operator to understand which repositories the developer was working with — valuable information for targeting additional attacks against CI/CD infrastructure or code repositories.
Why the attack was less harmful than it could have been
A critical point: coding errors in the malware prevented it from functioning as intended on most platforms. On macOS, the command `systemsetup -getremotelogin` returns code 0 with an error message when Remote Login is disabled — the malware interpreted that code as success and stopped trying to enable SSH. This means that on most Macs, the reverse tunnel was never established because the local SSH service was not running and the malware failed to activate it.
Even on systems where the tunnel was established, the connection required the remote server to accept the incoming connection and for the server settings to allow login via SSH key — which is uncommon in corporate environments. In other words, the malware planted the SSH key and installed persistence, but rarely managed to effectively open an interactive entry point.
Researchers at Daylight Security, who monitored real infection cases among developers, confirmed that at least two real cases were identified: in both, EDR tools triggered alerts (CrowdStrike logged PemFileWritten events when private keys were written to ~/.config/.smtk, and the IDE process ran SSH commands with `-R '*:0:localhost:22'`). However, the original Claude Code extension did not have any of the permissions the malware needed — and the attack relied entirely on trust vulnerabilities between the IDE and its extensions, not on a software flaw.
The role of Cursor and the response
Cursor was quick to act. Once the marketplace detected the malicious extension, it was removed, the marketplace was shut down entirely as a precaution, keys were rotated, and the marketplace was rebuilt before coming back online. Cursor confirmed that no other extensions were compromised and worked with the hosting provider to take the attacker's server offline.
The company also issued a security hardening guide, recommending that organizations restrict extensions to approved publishers and configure an installation cooldown — delaying the installation of newly published extension versions for a configurable period. These measures, however, protect only corporate organizations that explicitly adopt these settings. Individual developers who auto-update extensions remain vulnerable.
Cursor estimates up to 5,000 users were affected. The company published platform-specific remediation scripts, including instructions to remove the malicious LaunchAgent, the crontab entry, the Windows scheduled task, and the planted SSH key. The crucial point Cursor emphasized: uninstalling the extension does not remove the malicious artifacts — the attacker designed the malware to survive extension removal, writing artifacts outside the installation directory.
What this means for the future of developer security
This incident marks an inflection point. Historically, supply-chain attacks targeted npm libraries, PyPI packages, Git repositories, or CI/CD tools — targets that required the attacker to compromise widely distributed packages. The Claude Code extension, however, was a much more specific target: an IDE extension used by developers who were already configured with elevated permissions on their own computers.
Developers carry high-value credentials on their personal machines: SSH keys, AWS and GCP credentials, API tokens, authenticated CI/CD sessions. A malicious IDE extension has direct access to all of this — not just because it runs in the user's context, but because it can read files that other malware would never reach. The Claude Code extension malware needed no exploit — it simply ran as the IDE, with the same permissions.
The Claude Code extension is an emblematic case, but the pattern is broader. As developers adopt AI-powered coding tools — Claude Code, GitHub Copilot, Cursor, Windsurf — each of these tools offers extensions that run with IDE and user permissions. A single malicious plugin can deliver root access to the entire development environment.
What differentiates this attack from others is the level of planning. The malware was designed to persist even after the extension was uninstalled — which indicates the attacker was not seeking a quick, low-complexity installation, but rather persistent, long-term interactive access. The beacon sending environment variable names to the attacker's server suggests the intention was to use those variables as context for additional attacks, perhaps to pivot cloud accounts or access repositories.
The compromise vector — Cursor's extension marketplace — is also interesting. Cursor does not use the Visual Studio Marketplace or npm for distribution; its own marketplace is the distribution channel. This means the attacker did not need to compromise Anthropic's official distribution system (which, per the company, was unaffected), but rather exploit Cursor's extension review pipeline — or a team member with privileged access — to publish a trojanized version of the official extension.
The open question is whether AI-powered IDE extensions can ever be fully trusted without fundamental changes to how extension marketplaces operate. Until there is a cryptographic signing requirement for extensions, runtime isolation for extension code, or mandatory review processes that go beyond simple automated checks, developers installing extensions in their IDEs are, effectively, making a leap of faith.
Sources: Cursor, Microsoft Security Research, Netskope Threat Labs
✓ Independent sources cross-checked and verified before publishing
