Anatomy of a Supply-Chain Backdoor: Engineering Lessons from the Claude Code Extension
By Arash Latifi
A technical teardown of the Claude Code backdoor on the Cursor Marketplace: the IIFE injection into extension.js, the macOS systemsetup bug that broke the whole chain, reverse SSH tunneling via -R *:0, and the persistence artifacts — with detection commands and IOCs.
TL;DR — The Claude Code backdoor (2.1.312/2.1.313) is a masterclass in supply-chain anatomy: an IIFE injected before
activate, anfs.appendFileSyncwrite toauthorized_keys, asystemsetupbug that broke the macOS chain, and a-R *:0reverse tunnel — all in JavaScript, no privilege exploit required.
On October 29, 2026, compromised versions of the official Claude Code extension spent roughly 11 hours on the Cursor Marketplace. Between Phorion's reverse-engineering write-up and Cursor's incident notice, there is enough detail for a full engineering lesson: this malware is written in JavaScript, works without any privesc exploit, and only failed to achieve full compromise on most machines because of two bugs in itself. Let's walk through it.
Stage 0: injection before activate
The minified extension.js starts with an injected IIFE that imports standard Node modules:
The key detail: because this code runs at module scope, it executes as soon as Node loads the file — before the extension's normal activate callback ever fires. No user interaction is needed; installing and opening the editor is enough.
Stage 1: the SSH key and the macOS bug
The payload appends the attacker's Ed25519 public key (comment svc-telemetry) to authorized_keys via fs.appendFileSync. For threat hunters: the reinstall check only looks for the comment string, not the key itself — so in testing, check the key fingerprint, not just the comment.
Next it tries to enable the SSH daemon, and here comes the malware's golden bug on macOS:
But systemsetup -getremotelogin without administrator rights on macOS prints this and exits with status 0:
You need administrator access to run this tool... exiting!
Since the output is not Off, the condition fails and the enablement command never runs. The malware effectively treats "I can't check" as "SSH is already on". On a Mac without Remote Login enabled, the attacker's inbound path dead-ends — though the planted key and persistence remain. Cursor's notice independently confirms the enablement step "would fail" without admin privileges.
Lesson: a state check without proper error handling can break an entire attack chain — or your own feature.
Stage 2: the reverse SSH tunnel
For egress, the script writes an embedded private key (comment svc-telemetry-tun) to the temp directory as .stk_ plus the first 10 hex chars of the MD5 of hostname + home path:
Then it establishes the tunnel (via autossh if installed, else ssh):
The *:0 trick means the attacker's server dynamically allocates a listening port and forwards anything hitting it through the tunnel to the victim's localhost:22. The operator then connects from a separate session and logs in with the Stage-1 key. In the victim's SSH logs, these logins appear to come from 127.0.0.1 — a useful detection idea. The retry loop is detached (every 60 seconds, pgrep-guarded), so closing the editor does not kill the tunnel.
Stage 3: persistence, Stage 4: beacon
| Platform | Artifacts | Mechanism |
| --- | --- | --- |
| macOS | ~/Library/LaunchAgents/com.apple.sysmond.plist | LaunchAgent with RunAtLoad + KeepAlive |
| Linux | ~/.config/.smt, .smtk | @reboot entry in the user's crontab |
| Windows | %APPDATA%/.../Startup/sysmon.cmd | SysMon scheduled task (SYSTEM attempt) + Startup fallback |
Notably, the LaunchAgent masquerades with a fake com.apple.sysmond label — but any non-Apple process writing a com.apple.* plist is a strong detection signal in itself.
The beacon is equally simple: hostname, username, architecture, Git email, public IP (via ifconfig.me / api.ipify.org), and the names only of up to 40 env vars matching /KEY|TOKEN|SECRET|PASS|AWS|GCP/i, POSTed to /beacon on port 8099. Names only — but enough for the operator to prioritize which hosts to pursue.
Check your machine
- [ ] Ran the
svc-telemetrycheck (macOS/Linux and Windows PowerShell) - [ ] Confirmed persistence artifacts (
.smt,.smtk,com.apple.sysmond.plist,/tmp/.stk_*) are absent - [ ] Reviewed SSH logs for
127.0.0.1logins authenticated with a suspicious key - [ ] If flagged: ran Cursor's official
remediate-macos.sh/remediate-windows.ps1 - [ ] Rotated credentials and sessions accessible to the affected user, from a trusted machine
Cursor states the attacker's server is offline and there is no evidence other versions or the official distribution are affected — but still recommends remediation regardless, because uninstalling the extension does not remove the persistence.
Q: Why can a marketplace extension take over the whole machine?
Extensions run with the permissions of the IDE and the user. That means full access to local files, source code, and dev tooling (git, ssh, env vars). The marketplace does not sandbox code running inside the extension host.
Q: How did it work without a privilege-escalation exploit?
It didn't need one — it stayed in the user's context. The SSH key targets that same user's authorized_keys, and enabling a system service was only attempted via sudo -n, which fails without cached sudo. The macOS bug meant that even that step usually never ran.
Q: What is the single best detection signal?
Two: an IDE Helper process (Cursor Helper / Code Helper) writing authorized_keys directly via fs.appendFileSync (process-only rules watching echo/tee will miss it), and ssh/autossh running with -R *:0:localhost:22 and an identity file from /tmp/.stk_* or ~/.config/.smtk.