Malicious Claude Code Cursor Extension: Detect and Remove the Persistent SSH Backdoor

Microsoft’s October 30, 2026 analysis of a malicious Claude Code–branded Cursor extension is a high-priority warning for development and security teams. The extension abused a trusted AI-product identity to get code running in a developer’s editor context, then established persistent SSH-based unauthorized access. Closing Cursor or uninstalling the extension does not, by itself, remove that access.

The immediate risk is not limited to one workstation. Developer endpoints commonly hold source code, Git credentials, cloud tokens, signing material, deployment access, and trusted network paths into production. An SSH foothold on one of these systems can therefore become a source-code theft, credential-compromise, or downstream supply-chain incident.

Treat a confirmed installation as a security incident: isolate the host, preserve evidence, remove both the extension and its SSH persistence, rotate exposed credentials, and hunt for the same extension across the fleet.

What Microsoft Reported—and What It Did Not

Microsoft describes a malicious extension branded as Claude Code and distributed for Cursor, together with a persistent SSH backdoor mechanism. This is malicious-package and brand-abuse activity, not evidence that Cursor itself or Anthropic’s legitimate Claude Code product contains a software vulnerability.

Based on the supplied reporting:

• Affected users: Cursor users who installed the malicious Claude Code–branded extension.
• Affected assets: Developer workstations, jump hosts, build systems, and other endpoints on which the extension executed and SSH access could be established.
• Platforms: Cursor is used across Windows, macOS, and Linux, but defenders should use Microsoft’s sample-specific indicators to determine the payload’s platform scope. SSH persistence artifacts should be checked on every potentially exposed operating system rather than assuming only Linux is affected.
• Versions and extension identifiers: No affected Cursor version, malicious extension ID, publisher ID, or package version is provided in the supplied summary. Do not guess these values; obtain them from Microsoft’s analysis and compare them with local extension inventory.
• CVE and CVSS: No CVE is identified in the supplied reporting, so there is no CVE-specific CVSS score or patch level to apply.
• Exploitation status: Microsoft’s analysis confirms a real malicious extension, not a theoretical persistence technique. The summary does not establish victim counts, prevalence, or a CISA Known Exploited Vulnerabilities listing. No CISA or vendor remediation deadline is supplied.

Primary source: Microsoft Security Blog — Inside a malicious Claude Code-branded Cursor extension and its persistent SSH backdoor.

Technical Analysis: Why the SSH Component Changes the Incident

A malicious editor extension executes with the permissions available to the extension host and, normally, the developer who launched the editor. That position provides access to user-readable files and the ability to create processes, modify user configuration, and interact with network services. It does not automatically imply kernel compromise or administrator access, but the consequences can still be severe because developer accounts are unusually credential-rich.

The defensive attack chain to investigate is:

1. Trust and installation. The victim selects an extension using the Claude Code name or branding. Display names and logos are not proof of publisher identity.
2. Execution in the editor context. The extension’s code runs when installed, activated, or invoked, depending on its manifest and implementation.
3. SSH access establishment. The payload creates or modifies the components needed for unauthorized SSH access. The highest-priority persistence artifacts are SSH authorized-key files, SSH daemon configuration and included configuration files, and any nonstandard AuthorizedKeysFile locations.
4. Persistence outside the extension lifecycle. Once an attacker-controlled key or equivalent SSH trust change is in place, the access path can survive editor closure, extension disablement, and extension removal.
5. Post-access exposure. Interactive or automated SSH access can expose source repositories, developer credentials, internal network routes, and deployment systems.

This distinction matters during eradication. Removing the malicious package addresses the initial execution vehicle; it does not prove that the access it created has been revoked.

Scope the Host Correctly

Do not limit triage to the interactive user’s ~/.ssh/authorized_keys. Review:

• Every local account’s authorized_keys and legacy authorized_keys2 files.
• /etc/ssh/sshd_config and files included from /etc/ssh/sshd_config.d/ on Linux and other Unix-like systems.
• Effective SSH daemon settings, including AuthorizedKeysFile, PubkeyAuthentication, PermitRootLogin, and account or group restrictions.
• Windows OpenSSH locations such as C:\ProgramData\ssh\administrators_authorized_keys, C:\ProgramData\ssh\sshd_config, and user-profile .ssh directories where Windows OpenSSH is present.
• SSH authentication logs around the extension’s installation and first execution, looking for accepted public-key authentication and unfamiliar source addresses.
• Other accounts and hosts to which the developer’s recovered credentials or SSH keys could provide access.

File timestamps are supporting evidence, not proof. They can be changed, preserved by installers, or misleading after system restores. Compare key fingerprints and configuration content against an owner-approved inventory.

Detection and Response

Start with an extension-installation timeline, then correlate editor or extension-host activity with SSH file changes and authentication. Retain the extension directory, package manifest, editor logs, relevant EDR telemetry, SSH configuration, and a copy of authorized-key files before making changes.

The following rules are deliberately behavior-based. The supplied summary does not provide hashes, domains, package IDs, or attacker public keys, so none are invented here. Validate detection logic in a test environment and tune only for documented administrative workflows—not by excluding broad process classes such as Node.js.

Sigma: Process and Command-Line Behavior

These rules detect command-driven SSH persistence. Direct file writes performed inside an extension through a filesystem API may not generate a useful child-process command line, which is why file telemetry and the subsequent endpoint hunts are also necessary.

---
title: Editor Or Extension Host Command Modifying SSH Persistence
date: 2026/10/30
id: 6a84cf37-20e8-4a68-98cb-34df2f62cb71
status: experimental
description: Detects a shell or command launched by Cursor, another editor, or Node.js that references and attempts to modify SSH authorized-key or daemon-configuration artifacts. Useful for identifying malicious extension behavior and unauthorized SSH persistence.
references:
  - https://www.microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/
  - https://attack.mitre.org/techniques/T1098/004/
author: Security Arsenal
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\Cursor.exe'
      - '\Code.exe'
      - '\node.exe'
  selection_target:
    CommandLine|contains:
      - 'authorized_keys'
      - 'administrators_authorized_keys'
      - 'sshd_config'
  selection_change:
    CommandLine|contains:
      - 'Add-Content'
      - 'Set-Content'
      - 'Out-File'
      - 'echo '
      - 'printf '
      - '>>'
      - 'copy '
      - 'curl '
      - 'wget '
      - 'Invoke-WebRequest'
  condition: selection_parent and selection_target and selection_change
falsepositives:
  - Developer or administrative commands intentionally managing SSH configuration from an editor-integrated terminal
level: high
---
title: Shell Command Modifying SSH Authorized Keys Or Daemon Configuration
date: 2026/10/30
id: 0dbbf22b-664f-4093-980f-e32189c43a5e
status: experimental
description: Detects Linux command lines that combine modification behavior with references to SSH authorized-key files or daemon configuration. Hunt results should be correlated with editor execution, extension installation, and approved administration.
references:
  - https://www.microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/
  - https://attack.mitre.org/techniques/T1098/004/
author: Security Arsenal
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_target:
    CommandLine|contains:
      - 'authorized_keys'
      - 'sshd_config'
  selection_change:
    CommandLine|contains:
      - 'echo '
      - 'printf '
      - 'tee '
      - 'sed '
      - 'curl '
      - 'wget '
      - '>>'
      - 'cp '
      - 'mv '
  condition: selection_target and selection_change
falsepositives:
  - Configuration management and legitimate SSH administration
  - Developer setup scripts that install an administrator-approved public key
level: medium

For the Windows rule, an integrated terminal intentionally running an SSH administration command can be legitimate. Investigate the extension inventory, parent process, file content, and user context before assigning a verdict. For the Linux rule, use it initially as a hunt or medium-severity alert in environments with configuration-management activity.

Microsoft Sentinel and Defender Hunt

This query combines relevant process command lines with file modifications. It intentionally avoids returning every Node.js or Cursor process, which would create an unmanageable amount of developer telemetry. Extend the 30-day window if extension installation may have occurred earlier.

let lookback = 30d;
let proc = DeviceProcessEvents
    | where TimeGenerated >= ago(lookback)
    | where ProcessCommandLine has_any ('authorized_keys', 'administrators_authorized_keys', 'sshd_config')
    | project TimeGenerated, EvidenceType = 'Process', DeviceName, AccountName,
              ActionType, FileName, ProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine,
              FolderPath = '', SHA256;
let files = DeviceFileEvents
    | where TimeGenerated >= ago(lookback)
    | where ActionType in ('FileCreated', 'FileModified', 'FileRenamed')
    | where FileName in~ ('authorized_keys', 'authorized_keys2', 'administrators_authorized_keys', 'sshd_config')
         or FolderPath has 'sshd_config.d'
    | project TimeGenerated, EvidenceType = 'File', DeviceName, AccountName,
              ActionType, FileName, ProcessCommandLine = InitiatingProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine,
              FolderPath, SHA256;
union isfuzzy=true proc, files
| order by TimeGenerated desc

For each hit, answer three questions: Was the change approved, which process initiated it, and did an unfamiliar public key or SSH trust setting appear? A file event near first use of the suspect extension deserves priority even if no matching child-process event exists.

Velociraptor: Collect SSH Persistence Artifacts

The following hunt enumerates common authorized-key and SSH daemon configuration locations across Linux, macOS, and Windows. It returns public-key material for fingerprint comparison; it does not collect private keys. Protect the results as incident evidence and supplement the hunt when sshd -T reveals a nonstandard AuthorizedKeysFile path.

LET files <= glob(globs=[
  '/root/.ssh/authorized_keys',
  '/root/.ssh/authorized_keys2',
  '/home/*/.ssh/authorized_keys',
  '/home/*/.ssh/authorized_keys2',
  '/Users/*/.ssh/authorized_keys',
  '/Users/*/.ssh/authorized_keys2',
  '/etc/ssh/sshd_config',
  '/etc/ssh/sshd_config.d/*.conf',
  'C:/Users/*/.ssh/authorized_keys',
  'C:/ProgramData/ssh/administrators_authorized_keys',
  'C:/ProgramData/ssh/sshd_config'
])
SELECT FullPath, Size, Mode, Mtime,
       if(condition=FullPath =~ '(?i)authorized_keys2?$',
          then=read_file(filename=FullPath, length=65536),
          else='') AS KeyMaterial
FROM files
ORDER BY Mtime DESC

A key’s presence is not inherently malicious. Establish ownership by comparing its fingerprint with the user’s documented provisioning process, endpoint-management records, or an approved key inventory.

Linux Triage and Verification Script

This read-only endpoint script inventories SSH persistence artifacts, records hashes and public-key fingerprints, captures effective daemon settings when possible, and lists Cursor extension manifests. It deliberately does not delete keys or restart SSH; automated deletion can destroy evidence or lock administrators out. Run it as root, send its output to protected evidence storage, and review the manifest before remediation.

#!/usr/bin/env bash
set -euo pipefail

OUT="${1:-/var/tmp/cursor-ssh-triage-$(date -u +%Y%m%dT%H%M%SZ)}"
umask 077
mkdir -p "$OUT"

{
  date -u
  hostname
  uname -a
} > "$OUT/host.txt"

roots=()
for path in /root /home /etc/ssh; do
  [[ -d "$path" ]] && roots+=("$path")
done

manifest="$OUT/ssh-files.txt"
: > "$manifest"

if ((${#roots[@]})); then
  while IFS= read -r -d '' file; do
    {
      printf '\nPATH: %s\n' "$file"
      stat "$file" || true
      sha256sum "$file" || true
      case "${file##*/}" in
        authorized_keys|authorized_keys2)
          ssh-keygen -lf "$file" 2>&1 || true
          ;;
      esac
    } >> "$manifest"
  done < <(find "${roots[@]}" -xdev -type f \
    \( -name authorized_keys -o -name authorized_keys2 \
       -o -name sshd_config -o -path '*/sshd_config.d/*.conf' \) -print0)
fi

if command -v sshd >/dev/null 2>&1; then
  sshd -t > "$OUT/sshd-config-test.txt" 2>&1 || true
  sshd -T > "$OUT/sshd-effective-config.txt" 2>&1 || true
fi

if command -v ss >/dev/null 2>&1; then
  ss -lntp > "$OUT/listening-sockets.txt" 2>&1 || true
fi

for dir in /root/.cursor/extensions /home/*/.cursor/extensions /home/*/.cursor-server/extensions; do
  [[ -d "$dir" ]] || continue
  find "$dir" -maxdepth 2 -type f -name package.json -print
done > "$OUT/cursor-extension-package-files.txt"

printf 'Triage output written to %s\n' "$OUT"
printf 'Review key fingerprints and extension manifests before changing the host.\n'

Remediation: Remove Both the Loader and the Access Path

1. Contain Without Destroying Evidence

Isolate confirmed or strongly suspected endpoints using EDR network containment or an equivalent control. If the host does not require SSH for business operations, block inbound SSH at the host or network boundary while preserving console or out-of-band administration.

Capture the extension directory and manifest, installed version and publisher fields, installation source, relevant process and file events, SSH configuration, authorized-key files, and authentication logs. Do not run the extension again to observe its behavior on a production workstation.

2. Identify and Remove the Malicious Extension

Use Microsoft’s report to match the exact extension and publisher identifiers, hashes, versions, and infrastructure. Do not identify packages solely by the words Claude Code in a display name.

After evidence collection, disable and uninstall the confirmed malicious extension through Cursor or approved endpoint-management tooling. Then enumerate the same identifier across all developer endpoints, including remote development environments and home-managed systems used for company work. Removing one local copy is not fleet-wide eradication.

3. Revoke SSH Persistence Explicitly

For each SSH trust artifact:

• Preserve a copy and calculate its hash.
• Compare every public-key fingerprint with an approved owner or provisioning record.
• Remove only confirmed unauthorized keys, or place the host in a clean rebuild path if ownership cannot be established reliably.
• Revert unauthorized changes to sshd_config, included configuration files, custom AuthorizedKeysFile paths, and Windows OpenSSH configuration.
• Review other local accounts, especially service, deployment, root, and administrator accounts—not only the user who installed Cursor.
• Validate Linux SSH configuration with sshd -t, inspect the result with sshd -T, and verify an alternative administrative session before reloading the daemon.

Correct ownership and permissions after repair, but do not mistake a permissions cleanup for revocation of an attacker-controlled key.

4. Investigate Use of the Backdoor

Review SSH authentication records from the earliest possible extension installation time through remediation. Prioritize successful public-key authentication, unfamiliar source networks, logins outside normal working patterns, and access to accounts that were not expected to use SSH.

On Linux, review the distribution’s SSH service logs, commonly auth.log, secure, or the systemd journal. On Windows, review OpenSSH operational logging and endpoint network telemetry where available. Absence of logs is not evidence of absence; developer workstations often have short retention or no running SSH server until configuration changes.

Search for access to adjacent source-control, build, and production systems using credentials available on the compromised endpoint.

5. Rotate Credentials and Decide Whether to Rebuild

Because extension code ran in a developer context, rotate or revoke credentials that were accessible to that user, based on actual exposure:

• Git and source-control tokens.
• Cloud CLI credentials and deployment tokens.
• API keys stored in user-readable configuration or environment files.
• SSH private keys whose passphrases or agents may have been accessible.
• Active sessions and cached credentials supported by the relevant identity provider.

Changing the account password alone does not revoke an SSH authorized key or an exposed access token.

Rebuild from trusted media when the payload obtained elevated privileges, system-level SSH configuration was altered, evidence is incomplete, or high-value credentials and signing material were exposed. A clean rebuild is also appropriate when the response team cannot confidently enumerate all persistence changes.

6. Verify Eradication

Before returning the endpoint to service, confirm that:

• The malicious extension identifier is absent from all extension locations.
• No unknown authorized keys or unauthorized SSH configuration includes remain.
• Effective SSH configuration matches the approved baseline.
• No unexpected SSH listener, accepted login, or outbound access associated with the incident remains.
• Exposed credentials have been revoked and tested as unusable where the provider permits.
• EDR and file-monitoring coverage will detect a recurrence.

There is no CVE-specific Cursor patch or fixed version to prescribe from the supplied reporting. The remediation is package removal, persistence revocation, credential rotation, and—where assurance is insufficient—reimaging. Continue applying legitimate Cursor and Claude Code updates through verified publisher channels, but do not present an editor update as a substitute for incident response.

Preventive Controls for Development Environments

1. Govern extensions like software dependencies. Maintain an approved catalog based on full extension and publisher IDs, repository provenance, and reviewed versions. Display names and brand marks are insufficient.
2. Inventory remote development environments. Include local Cursor installations, remote extension hosts, developer containers, virtual machines, and build agents in software inventory and EDR coverage.
3. Baseline SSH trust. Continuously inventory authorized-key fingerprints and daemon configuration. Alert on changes outside configuration management, and use short-lived SSH certificates where practical to reduce dependence on unmanaged static keys.
4. Reduce developer standing privilege. Separate everyday development accounts from production administration, use short-lived cloud credentials, and avoid leaving broad-scope tokens on workstations.
5. Restrict SSH exposure. Disable SSH servers that are not required, limit source addresses at network controls, and prevent developer workstations from becoming unintended lateral-movement jump hosts.
6. Protect extension telemetry. Retain process lineage, file modifications, extension manifests, and relevant network events long enough to investigate a package that may remain dormant before activation.

The central lesson from Microsoft’s analysis is straightforward: a malicious extension can be the installer, while SSH becomes the durable access mechanism. Response plans that stop at extension removal leave the most important part of the incident unresolved.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub