A malicious update can arrive under the right extension ID. The corrected 30 October 2026 report from The Hacker News describes a trojanized anthropic.claude-code package, version 2.1.313, delivered through Cursor's extension marketplace. Its added code attempted to establish persistent SSH access while leaving the legitimate extension code in place.
The immediate questions are practical: did a workstation receive that package through that channel, did its loader execute, and what survived outside the extension directory? A working Claude Code interface or a subsequent update cannot answer all three.
Source basis. This edition reviews a supplied copy of the corrected report and its accompanying OpenSourceMalware attack-chain diagram. Cursor's statements are attributed through that reporting. This is not an independent examination of the malware or an affected workstation. The original vendor notice is linked below but was not independently retrieved for this edition.
What was affected, and what the correction changes
| Item | What the supplied reporting establishes |
|---|---|
| Package identity | The modified package identified itself as anthropic.claude-code, version 2.1.313, using the legitimate extension identity. It was not presented as a separate lookalike extension. |
| Delivery channel | The corrected report identifies Cursor's marketplace. The method used to introduce the unauthorized package remains unclear. |
| Reported installation window | Approximately 02:27–13:35 Pacific Time on 29 October 2026. At that date the offset is PDT, UTC−7. |
| Exposure estimate | Cursor estimated at most 5,000 users installed the malicious version. This is an installation-exposure estimate; the report does not provide a successful-SSH-login count. |
| Other marketplaces | The corrected report says there is no evidence that this package reached Open VSX or Microsoft's VS Code Marketplace. That is the scope of the report, rather than an independent audit of every distribution channel. |
| Removal and replacement | The report says the bad package was removed and that Anthropic had published 2.1.314 to Open VSX and Microsoft's marketplace by 30 October. A newer installed version does not establish that earlier host changes were cleaned up. |
| Other Cursor extensions | Cursor is quoted as saying the incident did not affect other marketplace extensions. No separate investigation of those extensions is presented here. |
For Japanese readers, the reported distribution window is 18:27 on 29 October to 05:35 on 30 October JST. In UTC it is 09:27–20:35 on 29 October. These conversions apply to the approximate distribution window, not to every possible activation or later use of persistence.
The source includes an explicit correction: an earlier version attributed the compromise to Open VSX; the later account identifies Cursor's marketplace. A screenshot of an Open VSX listing does not establish that Open VSX served the malicious artifact. Nor can a listing's cumulative download counter measure exposure to this particular Cursor-delivered package.
Cursor's statement that Anthropic did not develop the malicious modification is compatible with the package carrying Anthropic's legitimate extension ID. Publisher identity and delivered package integrity are separate checks. Neither fact establishes a compromise of Anthropic's source repository or publisher credentials; that entry mechanism remains unknown.
What the loader reportedly did
The report quotes OpenSourceMalware co-founder Jenn Gile describing a 66-line loader prepended to the legitimate extension.js bundle. It activates after editor startup and when the extension's webview opens. The supplied diagram says errors are suppressed and the legitimate extension still loads. Successful ordinary use of the extension would therefore be a poor safety test.
Figure 1. Original explanatory diagram based on the supplied report and OpenSourceMalware diagram. It summarises reported behaviour, rather than reconstructing a victim's activity.
The reported sequence is:
- Insert an SSH key. Add an attacker-controlled public key to
~/.ssh/authorized_keys, with the commentsvc-telemetry. - Prepare remote access. Attempt to make the local SSH service available and create an outbound reverse tunnel to
134[.]209[.]82[.]225. - Persist. The supplied macOS path uses a LaunchAgent named
com.apple.sysmondand a script at~/.config/.smt. The diagram also depicts associated key material, temporary.stk_*files and reconnection behaviour. - Send host reconnaissance. Transmit a host profile over unencrypted HTTP to the same address on TCP 8099, path
/beacon.
Platform evidence needs care. The text describes cross-platform branches using a Windows scheduled task, Linux cron and a macOS LaunchAgent. The supplied diagram specifically marks its Linux and Windows branches as not run by that build. It is evidence for those depicted code paths, not proof of successful deployment or confirmed victims on every operating system. The diagram names SysMon and an @reboot entry as investigation leads for the respective branches.
No follow-on payload was observed in the analysis described by the report. That finding is limited to the analysis: a usable SSH session would itself allow commands or file transfers, without requiring another malware download first.
Why an SSH-service failure does not finish the investigation
Cursor is quoted as saying that enabling the local SSH service requires administrator rights on most macOS and Windows hosts, and that the malicious extension generally lacked those rights. Where that step failed and no usable local SSH service existed, the intended SSH login path would not have worked.
The same quoted explanation says key insertion, persistence and host-information transmission still occur. Those effects need investigation and recovery even where the remote-login prerequisite was absent.
Our security analysis: also check whether SSH was already available before the incident. A failed attempt to start a service cannot establish its previous state. Whether the tunnel could provide access depends on the actual listener, its authentication policy, the inserted key and the tunnel's success. An outbound reverse tunnel also changes the network question: an inbound perimeter block on port 22 alone does not demonstrate that an outbound tunnel could not reach a workstation's local SSH service.
Figure 2. The reported upper bound belongs to installation exposure. The report supplies no measured conversion rate to successful remote access or credential theft.
What the initial beacon contained
The supplied report lists:
- public IP obtained through
api.ipify[.]org; - hostname, local username, operating system and CPU architecture;
- home directory and current working directory;
- the global Git email obtained with
git config --global user.email; - up to 40 environment variable names containing
KEY,TOKEN,SECRET,PASS,AWSorGCP.
Paul McCarty is quoted as explaining that environment-variable values were not placed directly in the initial beacon. Variable names can still reveal credential types, cloud providers and development systems. A working remote session would create an additional opportunity to inspect the account.
Keep those evidence levels distinct. The reported initial beacon does not demonstrate that it directly contained API-key values. It also does not establish that all credentials accessible to a later operator remained confidential. Credential decisions need the endpoint execution evidence and the audit records of the services those credentials could reach.
Indicators and their limits
These indicators are transcribed from the supplied report or diagram, with reporting cutoff 30 October 2026. Addresses are defanged here. A match requires context; the observation window and artifact coverage are limited by those sources.
| Indicator | Type and reported role | Investigation limit |
|---|---|---|
anthropic.claude-code / 2.1.313 / Cursor delivery |
Package/version/channel combination | A version label is an inventory lead. Preserve the actual package and establish its origin; do not classify every same-numbered package from another channel as malicious solely by version. |
134[.]209[.]82[.]225 |
Reported tunnel and beacon destination | Historical infrastructure indicator. Correlate the relevant endpoint, time, port and initiating process; address ownership or use can change. |
TCP 22 and 8099; HTTP path /beacon |
Reported tunnel connection and host-profile beacon | A connection event alone cannot prove an SSH login or the contents of an HTTP request. |
svc-telemetry |
Comment on the inserted SSH key | A comment is mutable and is not a cryptographic key fingerprint. Preserve the full public key and its context. |
com.apple.sysmond |
Reported macOS LaunchAgent label | A familiar-looking label needs its plist, executable target and timestamps checked. |
~/.config/.smt; temporary .stk_* files |
Script and key-material artifacts depicted for the macOS path | Filename patterns are weaker than an attributed artifact hash and can be changed or collide with other files. |
@reboot; SysMon |
Linux cron and Windows task branches depicted in the supplied diagram | Those branches are marked unexecuted by that build; inspect actual host evidence before asserting that either was installed. |
api.ipify[.]org |
Public-IP lookup service | A shared legitimate service. A request to it is not a standalone malware verdict. |
No VSIX or extracted-file SHA-256 was included in the supplied material, so none is reproduced here. If obtaining hashes from a later vendor update, record whether each identifies the archive, an extracted JavaScript bundle or another file. Compute and preserve hashes of collected evidence; do not compare different artifact types as though they were interchangeable.
Response: package recovery and workstation recovery
- Find potentially exposed endpoints. Identify Cursor installations, the actual extension source and installation/update records for the reported window. Automatic updates may explain exposure without a deliberate new install. Extend the timeline for later activation and persistent activity.
- Preserve evidence and contain active risk. Use the organisation's incident-response process to contain hosts with evidence of malicious execution. Preserve the VSIX or installed extension, update records, process trees, relevant network logs, SSH configuration and persistence definitions before destructive cleanup where feasible.
- Investigate access prerequisites and resulting activity. Establish the local SSH-service state, key insertion, tunnel creation and any authentication events. Correlate repository, registry, cloud, identity-provider and deployment audit records with the endpoint timeline.
- Remove known access and persistence through reviewed procedures. Use the current Cursor notice for vendor recovery guidance and verify its platform scope. Updating or uninstalling the extension does not remove every possible independently written host artifact. Do not blindly delete all SSH keys or similarly named legitimate startup entries.
- Scope credential and session revocation from a trusted device. Where malicious execution or usable persistence is established, assess the developer credentials and active sessions reachable from that account: repository, package registry, cloud, CI/CD, deployment and AI-provider access. Rotate or revoke as the exposure evidence and response policy require; review their use rather than assuming rotation alone resolves it.
- Decide whether cleanup restores sufficient confidence. Consider a managed rebuild when the execution history, accessible credentials or secondary activity cannot be bounded. Confirm the trusted package source, residual persistence checks and relevant service audits before returning the host to normal use.
| Team | Practical responsibility | Evidence to retain |
|---|---|---|
| IT Operations | Inventory Cursor, package origins and update history; manage trusted reinstallation | Device/package inventory, installed and cached artifacts, update timestamps. |
| EDR / incident response | Containment, execution-chain review and persistence recovery | Process trees, file writes, SSH state, key and startup definitions. |
| SIEM | Correlate host, network and service-account activity | Endpoint, network, SSH, repository, registry, cloud and identity logs. |
| Third-party Risk | Track vendor scope, corrections and recovery limitations | Dated notices, distribution-channel statements and package provenance. |
| Legal / Privacy | Assess any personal-data or contractual implications using established facts | Confirmed transmitted data and further access, affected identities and documented uncertainty. |
Scoped hunting examples
Validation status: the examples below were statically checked for indicator transcription, host/time bounds and bilingual/download consistency. They were not executed against a live tenant or production index.
The starter window is 29 October 09:00 UTC to 31 October 00:00 UTC, covering the approximate reported delivery period and some later activity. It is an investigation choice, not an assertion of the full intrusion period. Extend or move it when investigating delayed activation or persistence, and check log retention.
Microsoft Defender XDR: connections to the reported infrastructure
Requires Defender for Endpoint network telemetry in DeviceNetworkEvents, the listed fields, and Advanced Hunting access to the selected devices. Replace REPLACE_WITH_DEVICE_ID with the investigated device ID or IDs; do not remove the device filter merely to make the example run. Results are limited to 100.
// Microsoft Defender XDR / Defender for Endpoint: DeviceNetworkEvents.
// Replace the DeviceId list. This historical UTC window is a starting point;
// extend the investigation window for delayed activation or persistence.
let Start = datetime(2026-10-29T09:00:00Z);
let End = datetime(2026-10-31T00:00:00Z);
let TargetDevices = dynamic(["REPLACE_WITH_DEVICE_ID"]);
DeviceNetworkEvents
| where Timestamp between (Start .. End)
| where DeviceId in (TargetDevices)
| where RemoteIP == "134.209.82.225"
| where RemotePort in (22, 8099)
| project Timestamp, DeviceId, DeviceName, ActionType, RemoteIP, RemotePort,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
| take 100
Expected results are connection events to the reported address on the two reported ports, with initiating-process context. Inspect ActionType and correlated evidence to assess attempted or established activity. This query does not identify the /beacon request body or prove a completed SSH authentication. Missing telemetry, filtered egress, later infrastructure changes and a host outside the selected window are blind spots.
Microsoft Defender XDR: SSH process leads
Requires DeviceProcessEvents with process command lines and initiating-process fields, plus access to the selected devices. The same device and time replacements apply.
// Microsoft Defender XDR / Defender for Endpoint: DeviceProcessEvents.
// Replace the DeviceId list; correlate matches with package, file and network evidence.
let Start = datetime(2026-10-29T09:00:00Z);
let End = datetime(2026-10-31T00:00:00Z);
let TargetDevices = dynamic(["REPLACE_WITH_DEVICE_ID"]);
DeviceProcessEvents
| where Timestamp between (Start .. End)
| where DeviceId in (TargetDevices)
| where FileName in~ ("ssh", "ssh.exe", "autossh", "autossh.exe")
| where ProcessCommandLine contains "134.209.82.225"
or ProcessCommandLine contains ":0:localhost:22"
| project Timestamp, DeviceId, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
| take 100
This searches the reported destination or reverse-forward argument pattern in ssh/autossh process activity. Legitimate administration can use reverse SSH forwarding. Correlate the parent process, package history, keys and persistence; renamed binaries or changed arguments can evade this narrow search.
Splunk: network-log corroboration
Replace the index, sourcetype and investigated source IP. The example assumes your events expose src_ip, dest_ip, dest_port and action; adapt the field mapping to your data source. Your Splunk role must permit that index. The epoch bounds express the same UTC starter window regardless of the search head's display timezone. The displayed ctime values follow your Splunk timezone.
index=REPLACE_WITH_NETWORK_INDEX sourcetype=REPLACE_WITH_NETWORK_SOURCETYPE earliest=1793264400 latest=1793404800
src_ip="REPLACE_WITH_SOURCE_IP" dest_ip="134.209.82.225" (dest_port=22 OR dest_port=8099)
| stats count min(_time) AS first_seen max(_time) AS last_seen values(action) AS actions BY src_ip dest_ip dest_port
| sort 0 - last_seen
| head 100
| convert ctime(first_seen) ctime(last_seen)
This summarises observed traffic for one source host, with at most 100 rows. NAT can complicate source attribution, and network logs normally do not establish SSH authentication or file access. A zero-result search is not proof that the package never ran or that persistence is absent.
Sources and reporting limits
- The Hacker News, 30 October 2026: Official Claude Code Extension on Cursor Marketplace Trojanized with Persistent SSH Backdoor. A supplied copy, including the correction from Open VSX to Cursor, was reviewed for this edition.
- Cursor: Claude Code extension security notice. Vendor statements above are attributed through the supplied report; this original page was not independently retrieved for this edition.
- OpenSourceMalware: Trojanized Claude Code extension plants persistent SSH backdoor. The accompanying supplied attack-chain diagram was reviewed; the full original post and malware sample were not independently examined.
The marketplace entry mechanism, successful remote-login count and complete downstream impact remain unknown in the supplied reporting. The article makes no attribution to an attacker and no claim that Anthropic's repositories or publisher credentials were compromised.