Cursor’s Claude Code incident quick check can print “No key found; machine not impacted” without establishing whether the malware previously ran. Superpower Daily’s static comparison finds a narrower result: no successful match for a particular SSH-key comment in the checked files. That distinction separates a useful indicator check from a conclusion about a computer’s history.
Original analysis: We compared four supplied documents—Cursor’s incident notice, Phorion’s technical advisory, StepSecurity’s analysis and Kevin Beaumont’s public hunting queries. The question was what their results establish about package exposure, payload execution, persistence and successful remote access. This was a document comparison, not a host investigation: we ran no payload, check, cleanup script or query. The requested evidence cutoff was October 30, 2026, at 15:31 UTC; the snapshots’ exact versions at that cutoff are unverified.
The incident concerns malicious version 2.1.313 of the Claude Code extension, which Cursor says was not developed by Anthropic. Its October 29 security notice describes attempted persistent remote access and directs affected users to search telemetry, remove artifacts and rotate credentials. The quick check sits inside that broader response; it is not the only investigation step Cursor recommends.
A key-comment search is not a history check
The macOS command searches the current user’s SSH authorized_keys file for svc-telemetry, the comment attached to the attacker’s public key. SSH is a remote-login system; authorized_keys lists public keys accepted for authentication. Cursor’s command turns a successful text match into a warning and any unsuccessful result into the same reassuring message. The wording reaches beyond what the search itself establishes.
Scope matters. The macOS check examines that user’s file, not every user’s keys. Windows additionally checks administrators_authorized_keys. Neither negative result establishes that the payload never executed. On macOS, the command also suppresses grep errors, so failure to read the file can produce the same output as a completed search with no match. We did not test unreadable files, other user contexts or historical artifact removal.
A positive comment match has its own boundary. Phorion recommends verifying the public-key fingerprint—the identifier derived from the key—rather than relying only on its comment. The malware itself checks for the comment before appending a key. Verifying the attacker’s key establishes an unauthorized authentication artifact, not evidence that someone successfully used it to log in.
Four stages, four different evidentiary thresholds
- Package exposure: A matching malicious package hash identifies possession of that artifact. Installation establishes exposure, but neither alone proves execution. A version string is weaker still: it is a lead to investigate, not equivalent to identifying the malicious package. The distinction matters when interpreting broad searches across process commands or registry data.
- Payload execution: Phorion and StepSecurity identify loading extension.js as the trigger. The injected code runs before the extension’s normal activation callback; no Claude conversation is required. StepSecurity reports sandbox verification of module-load execution. Installation evidence alone does not show that this loading occurred on a particular computer.
- Persistence: A familiar filename is a hunting lead. Verified malicious script content and registration establish installed persistence: a macOS LaunchAgent, a Windows SysMon scheduled task or Startup fallback, or a Linux reboot cron entry. Those mechanisms arrange future launches. Their presence does not establish that a launch actually succeeded after reboot.
- Remote access: A recorded event involving the attacker’s address does not necessarily establish a connected tunnel. Even a verified tunnel is separate from operator login. The tunnel forwards traffic toward the victim’s local SSH service; successful authentication using the planted key is the further evidence needed to establish that access step.
The permission limit does not settle every Mac’s status
Cursor offers an important counterweight to the backdoor’s apparent reach: enabling the local SSH service requires administrator rights on most macOS and Windows hosts. Its notice says errors in the malicious code would block the access step outside unusual elevated-editor circumstances. It nevertheless says the extension adds the key, installs persistence and sends host details, and tells users to remediate regardless.
Phorion’s macOS analysis preserves a crucial exception: SSH may already be enabled. It describes the malware misreading an administrator-access error when checking Remote Login, then skipping enablement while still dropping keys and persistence. With SSH off, forwarded traffic reaches a closed local port. With SSH already on—or enabled later—the access path remains available. Non-elevated editor execution therefore cannot, by itself, resolve a host’s status.
Hunting results inherit the query’s boundaries
Beaumont’s public hunting queries search network, process, file and registry event tables. The attacker-IP query does not filter for connection outcome. Some package-search branches match 2.1.313 in process or registry data without independently identifying the package. Although the file labels some searches “high fidelity,” the individual conditions still determine what each result proves.
The SSH process search requires the immediate parent to be Code or Cursor. Detached or service-managed tunnels need not retain that parent relationship. The sampled queries also contain no explicit incident-time bound or successful-authentication search. Zero results mean no matching records in the queried telemetry; coverage, permissions, retention and execution-time settings still need verification. This comparison measures neither detection effectiveness nor compromise prevalence.
Cleanup status leaves a historical question
Cursor says its remediation scripts exit with a nonzero status if targeted artifacts remain. That contract concerns cleanup, not proof of no previous access. We could not inspect either script because retrieval failed on unsupported content types. Linux persistence appears in the technical analyses but falls outside Cursor’s published macOS and Windows quick-check and remediation-script scope.
StepSecurity recommends reviewing SSH, shell, process and authentication logs for follow-on activity. It also advises rebuilding rather than cleaning a host when a tunnel is confirmed connected. That is precautionary guidance, not proof that an attacker authenticated. The evidence to watch next is successful local SSH authentication using the planted key, alongside records of subsequent activity. Such findings would address what happened after setup—not merely whether the package or its artifacts were present.
Reader comments
Newest comments first. Replies stay oldest first.