Claude Code Extension Attack: How to Hunt the SSH Backdoor

The Claude Code extension attack turned a trusted developer update into a persistent backdoor. On October 30, 2026, fresh reporting confirmed that a maliciously modified build of Anthropic's Claude Code extension had been distributed through Cursor's extension marketplace, potentially reaching up to 5,000 users during an 11-hour window.

Version 2.1.313 did more than run once and disappear. It attempted to add an attacker-controlled SSH key, establish a reverse tunnel, install operating-system persistence, and report host details. Uninstalling the extension is therefore not enough. If your team uses Cursor, you need to find the affected version, isolate evidence-bearing hosts, remove every persistence path, and rotate credentials from a clean system.

Key Takeaway: Treat any machine that ran anthropic.claude-code 2.1.313 from Cursor's marketplace as a potential developer-workstation compromise, not as a routine bad-extension cleanup.

Why the Claude Code extension attack matters now

The Hacker News disclosed the confirmed marketplace compromise on October 30, 2026, making that same-day report the main news hook for this response guide. The incident shows how a familiar extension name and automatic update path can carry malicious code directly into an environment where source code, cloud credentials, package tokens, and production access often coexist.

Cursor's security notice says the malicious version was available from about 2:27 a.m. to 1:35 p.m. Pacific Time on October 29. Cursor says the package was not developed by Anthropic, no other extension versions or official distributions are known to be affected, and the attacker's server has been taken offline.

Those limits are important, but they do not close the incident. The payload could leave an unauthorized SSH key and persistence scripts behind even where the reverse tunnel failed. A dead command server reduces current attacker access; it does not restore host trust or invalidate credentials the machine could expose.

The risk is especially concentrated on developer endpoints because they commonly hold:

• GitHub or GitLab sessions and personal access tokens
• cloud command-line credentials and environment variables
• package registry and CI/CD secrets
• SSH keys for internal systems
• source code, signing material, and deployment access
• browser sessions for administrative services

Hexon's GitHub Actions secret-theft analysis explains the same underlying danger from another direction: developer and automation identities often connect code, infrastructure, and production. One compromised endpoint can therefore create several follow-on paths.

Key Stat: Cursor places the maximum affected population at 5,000 users. That figure describes potential distribution, not a confirmed count of successful SSH sessions or fully compromised hosts.

Understand what version 2.1.313 attempted to do

The malicious extension preserved the expected package identity while adding a compact loader to the legitimate bundle. Once loaded, it collected reconnaissance, attempted to enable remote access, and created mechanisms designed to survive application restarts.

The reported sequence was:

1. collect the hostname, username, operating system, CPU architecture, public IP, home directory, current working directory, and configured Git email
2. enumerate the names of environment variables containing terms such as KEY, TOKEN, SECRET, PASS, AWS, or GCP
3. append an attacker-controlled key labeled svc-telemetry to an SSH authorized_keys file
4. attempt to enable the local SSH service and create a reverse SSH tunnel
5. create persistence through a macOS LaunchAgent or Windows scheduled task and startup script
6. send host details and backdoor status to an HTTP endpoint on port 8099

Cursor notes that enabling SSH generally required administrator rights that the extension did not have on most macOS and Windows systems. Errors in the malicious code also limited that step. However, a failed tunnel is not proof of a clean machine because the key, scripts, retry logic, and reconnaissance could still be present.

Socket's independent review also found no matching publication record for 2.1.313 in Open VSX or npm. That distinction narrows the confirmed distribution path to Cursor's marketplace and prevents teams from expanding scope based on early, conflicting reports.

Common Mistake: Assuming that an inactive command server or failed privilege-dependent step means remediation can stop at updating the extension.

Find affected developer workstations

Start with extension inventory. Search endpoint-management, software-inventory, and IDE telemetry for anthropic.claude-code version 2.1.313, then correlate installations with the Cursor marketplace and the October 29 exposure window.

Do not rely only on a user's current extension list. Automatic updates may already have replaced the malicious version with 2.1.314, while persistence remains outside the extension directory. Retain installation history, file-system evidence, process records, and network telemetry before cleanup.

For each potentially affected endpoint, record:

• device owner and business role
• operating system and architecture
• installed extension version and installation source
• first-seen, update, and removal times
• whether Cursor ran with elevated privileges
• repositories, cloud accounts, and deployment systems reachable from the device
• presence of SSH, persistence, process, or network indicators
• credentials and sessions that existed during the exposure window

Cursor identifies svc-telemetry in SSH authorized-key files as a direct indicator. Teams should also search for com.apple.sysmond LaunchAgent artifacts on macOS, the SysMon task or sysmon.cmd startup fallback on Windows, hidden .smt, .smtk, and .stk_* files, plus reverse-tunnel command lines using ssh -N -R or autossh -M 0.

Network teams should look for connections to the reported attacker address on TCP 22 and HTTP port 8099. Public-IP lookups to common services are not sufficient on their own because legitimate applications use them too. Correlate weak signals with the malicious version, file indicators, or suspicious process execution.

The inventory discipline in Hexon's AI supply chain security guide applies directly here. You cannot investigate an update path if you do not know which developer tools, plugins, and marketplaces are present across the fleet.

Pro Tip: Separate three states in your incident tracker: installed 2.1.313, executed payload evidence, and confirmed interactive access. Each requires action, but they are not the same claim.

Contain and remove the SSH backdoor safely

Isolate any endpoint with the malicious version or a direct payload indicator. Preserve volatile and disk evidence where your incident process requires it, then perform remediation from a known-clean administrative system.

Use this order:

1. disconnect or contain the host without destroying evidence
2. capture running processes, network connections, login history, extension metadata, and relevant file timestamps
3. remove the attacker-controlled SSH key from every applicable authorized-key location
4. stop and remove the LaunchAgent, scheduled task, startup script, retry process, and hidden support files
5. remove version 2.1.313 and install a verified clean release, currently 2.1.314 or later
6. rescan for every published indicator and confirm remediation scripts return success
7. decide whether observed tunnel activity or elevated execution requires a full host rebuild

StepSecurity's technical analysis stresses that removing the extension alone does not remove standalone persistence. Cursor provides remediation scripts for macOS and Windows, but organizations should review scripts before execution, preserve evidence first, and validate the result with their own endpoint tooling.

If the reverse tunnel connected, SSH was enabled, or interactive access cannot be ruled out, rebuilding the workstation is safer than declaring a partial cleanup sufficient. Restore only reviewed files and re-enroll the endpoint through your standard secure build process.

Hexon's session revocation guide is relevant because resetting a password alone may leave tokens and sessions active. Endpoint recovery and identity recovery need to run as one coordinated workstream.

Key Takeaway: The cleanup target is not the extension. It is the complete attacker path: package, key, tunnel, persistence, credentials, sessions, and any downstream access.

Rotate developer credentials in the right order

Credential rotation should begin after the affected device is contained, using a separate trusted machine. Rotating secrets on a still-compromised host can immediately expose the replacements.

Prioritize credentials by reach and replay value:

1. revoke active browser and IDE sessions
2. rotate source-control personal access tokens and SSH keys
3. rotate CI/CD, package registry, artifact repository, and code-signing credentials
4. rotate cloud access keys and invalidate command-line sessions
5. reset administrative credentials for systems reachable from the device
6. review service-account use and issue narrowly scoped replacements

Environment-variable values were not reported in the initial beacon, but their names could reveal which providers and credential types were configured. More importantly, successful interactive access would allow the attacker to inspect files, shells, agents, browser data, and running processes directly.

Review recent repository activity, package publication, workflow changes, cloud audit logs, new SSH keys, OAuth grants, and authentication events tied to the developer. A quiet workstation can still be the starting point for a downstream software supply-chain incident.

The controls in Hexon's developer hiring malware response reinforce the broader lesson: developer workstations should not combine unreviewed code execution with durable production credentials and unrestricted trust.

Common Mistake: Rotating only the credentials whose names appeared in environment variables. Scope rotation to everything accessible from the endpoint during the possible compromise window.

Reduce extension marketplace risk after recovery

The Claude Code extension attack should trigger a control review, not a permanent ban on developer extensions. Teams need a managed path that preserves productivity while making distribution trust visible and reversible.

Build a baseline with these controls:

• maintain an allowlist of approved extensions, versions, publishers, and marketplaces
• inventory extensions continuously rather than during annual audits
• log installs, removals, automatic updates, and source registries
• stage high-impact updates before broad deployment
• verify package hashes or signatures where the ecosystem supports it
• block extension installation from unapproved marketplaces
• alert on missing versions, sudden publisher changes, or unexpected package-size shifts
• keep developer endpoints out of standing production-admin roles

Automatic updates create a specific tradeoff. Disabling them everywhere can leave known vulnerabilities open, while allowing immediate updates from every source converts marketplace compromise into rapid fleet-wide execution. A risk-based policy can permit fast updates from approved channels while staging privileged or high-reach developer tooling in a small ring first.

Design for developer endpoint compromise. Use short-lived cloud credentials, hardware-backed authentication, separate privileged workstations, restricted SSH agents, protected branches, signed releases, and independent approval for production changes. These controls reduce the value of any single stolen workstation session.

Finally, retain enough telemetry to reconstruct extension provenance. The decisive questions are often simple: which registry served the package, which version ran, when did it arrive, what did it launch, and what authority did that device have?

Verify recovery from the Claude Code extension attack

Close the incident only when host, identity, code, and marketplace evidence agree. A clean current version is useful, but it cannot prove that a previous payload did not persist or access downstream systems.

Your closure record should show:

• every in-scope endpoint and its extension history
• search results for the malicious version, hashes, key label, files, tasks, and processes
• containment, evidence preservation, cleanup, or rebuild decisions
• revoked sessions and rotated credentials
• review of repositories, pipelines, packages, and cloud activity
• verification from endpoint and network monitoring after recovery
• policy changes for extension inventory and update provenance

Continue monitoring for delayed use of developer identities. Watch for unusual repository access, new deploy keys, package releases, workflow edits, cloud role assumptions, and authentication from unfamiliar infrastructure.

The Claude Code extension attack is a reminder that an IDE extension is executable software operating close to some of the organization's most valuable access. Respond to version 2.1.313 as an endpoint and identity incident, remove persistence rather than only the package, and make extension provenance a permanent part of developer security.