Cursor Claude Code Extension Attack: Complete macOS and Windows Cleanup Guide

Key Takeaways

• The affected distribution was a tampered copy of Anthropic.claude-code version 2.1.313 in Cursor's marketplace. Cursor says Anthropic did not develop the malicious version and reports no evidence that other versions or the official distribution were affected.
• The reported distribution window was approximately October 29, 2026, 2:27 a.m.–1:35 p.m. Pacific Daylight Time. Cursor put the maximum affected population at 5,000 users. That is not a count of confirmed successful remote logins.
• The payload collected host information and attempted to establish persistent SSH access. Cursor reports important privilege and implementation limitations. Those limitations do not eliminate the need to check for unauthorized keys, persistence, and host-information disclosure.
• Uninstalling the extension alone can leave malicious components running. Cursor provides separate macOS and Windows remediation scripts.
• A missing svc-telemetry marker is a negative result for one indicator, not a forensic clean bill of health. Correlate extension contents, installation records, persistence, processes, and historical network telemetry.
• Use a trusted device to revoke exposed credentials and sessions. Cleanup cannot recover information already disclosed or invalidate credentials the attacker may have obtained.

What Happened and Who Should Investigate

In its October 29, 2026 security notice, Cursor reported that a maliciously modified Claude Code extension was available through its extension marketplace for roughly 11 hours and 8 minutes. The package retained the legitimate-looking extension identifier and version number. Cursor's remediation scripts therefore inspect extension contents for the malicious marker rather than deleting every installation with a particular version number.

Cursor says it removed the package, temporarily shut down its marketplace, audited access, rotated keys, rebuilt the marketplace, and restored service. Its notice says no other extensions were tampered with in that audit. Cursor also worked with the hosting provider to take the attacker server offline. These are Cursor's reported response actions; server takedown does not remove files already written to endpoints.

Investigate installations and updates from that channel during the window, including automatic updates. A machine that obtained the package then could execute it later. Reopening Cursor after the marketplace was repaired would not retroactively make an already downloaded malicious package safe.

Do not use today's installed version or a folder timestamp as the sole exposure test. Updates, deletion, restoration, and copied VSIX files can obscure history. Preserve editor installation logs, endpoint records, cached package provenance, and download telemetry where available. Check each relevant user account and extension location, including custom paths and remote extension hosts used in the workflow. The published notice identifies macOS and Windows artifacts; it does not establish a Linux-specific payload or justify declaring every other environment unaffected.

Cursor Marketplace, Microsoft Marketplace, and Open VSX Are Different

An extension ID identifies a name within a publishing ecosystem; it is not proof that downloads from different registries contain identical bytes.

Cursor's extension documentation explicitly warns that the same publisher.extension name can refer to different publishers or code across Open VSX and Microsoft's marketplace. That makes download provenance, publisher identity, package integrity, and actual file contents more useful than a familiar name alone.

The distinction is also reflected in Microsoft's marketplace documentation and the Eclipse Foundation's Open VSX FAQ: these are separate distribution systems with their own publishing and governance arrangements.

The notice does not disclose a complete root-cause account of how the attacker modified the package. It would be premature to describe this as a confirmed Anthropic account takeover, an Open VSX-wide breach, or a Microsoft signing failure. The marketplace controls described in current documentation also should not be treated as proof of which controls operated successfully before the incident.

Technical Analysis: What the Payload Did and Attempted

Host discovery and reporting

Cursor reports collection of the hostname, username, operating system, architecture, home-directory path, environment-variable names, working directories, configured Git email, and public IP. The payload attempted to report host details and backdoor status through HTTP POST requests to /beacon on port 8099.

Environment-variable names are different from their values. The disclosure does not establish that the initial collection routine dumped every API key or password. However, the potential for later access through a working backdoor is why Cursor recommends credential and session rotation.

Unauthorized SSH access

The payload attempted to add an attacker-controlled SSH public key, enable the local SSH service, and create a reverse SSH tunnel. Conceptually, the tunnel would make a local SSH service reachable through an outbound connection to attacker infrastructure. It would still require the relevant tunnel, SSH listener, authentication configuration, and permissions to work.

Cursor says coding errors and the need for administrator privileges prevented the access setup from working in ordinary non-administrator circumstances. The notice nevertheless says that unauthorized key insertion, persistence installation, and host-detail reporting could still occur. Do not equate a failed attempt to enable SSH with no compromise. An existing SSH service is also relevant to investigation, although its presence alone does not prove successful attacker access.

Persistence outside the extension

On macOS, the published artifacts include a user LaunchAgent named com.apple.sysmond and hidden files under ~/.config. On Windows, the payload attempted to create a SysMon scheduled task running as SYSTEM, with a Startup-folder script as a fallback. Cursor says background scripts retried the tunnel approximately every 60 seconds.

These standalone components explain why disabling or uninstalling an extension is insufficient: the operating system can continue launching a script that no longer depends on the extension being installed. The Apple-like label and SysMon task name are camouflage indicators in context, not grounds for deleting every similarly named operating-system or monitoring component.

Confirmed findings versus possible consequences

Microsoft's extension runtime security documentation explains that extensions run with the editor's permissions and can access files, launch processes, and make network requests. That explains the general security sensitivity of developer extensions; it is not evidence that every capability was exercised in this incident.

Before Checking or Cleaning a Device

1. For suspected execution, contain the host. Use your endpoint response platform's isolation function or disconnect ordinary network access. Preserve an approved management channel if your security team requires it.
2. Preserve evidence before destructive cleanup. Record UTC timestamps, relevant extension folders and hashes, suspicious scripts, SSH key files, task definitions, launchd configuration, and process/network telemetry. Keep evidence access-controlled; it may contain sensitive local information.
3. Close Cursor and other VS Code-based editors before remediation. Enterprise responders may capture volatile process evidence first. Do not reopen a suspect extension to see whether it works.
4. Obtain the current scripts from Cursor's official notice using a trusted system. Transfer reviewed files through an approved route if the affected machine is isolated.
5. Use the correct account context. The macOS script must run separately as each affected user without sudo. The Windows script requires an elevated PowerShell session and enumerates user profiles.

The checks below are read-only investigation commands. They do not connect to the attacker. Missing files, permission errors, incomplete telemetry, or an unavailable command should be recorded as investigation limitations, not translated into “clean.”

macOS Checks

1. Inspect extension versions and contents without loading them

Run this in Terminal. The explicit Bash block also works when the interactive shell is zsh. It examines the hidden-home-directory extension layout used by Cursor's remediation script; add custom extension locations separately.

bash <<'BASH'
shopt -s nullglob
for dir in "$HOME"/.[!.]*/extensions/anthropic.claude-code-*; do
  [ -d "$dir" ] || continue
  printf '\nExtension directory: %s\n' "$dir"
  if [ -r "$dir/package.json" ]; then
    /usr/bin/plutil -extract version raw -o - "$dir/package.json"
  else
    printf 'Manifest missing or unreadable\n'
  fi
  if [ -f "$dir/extension.js" ]; then
    grep -qE 'svc-telemetry|134[.]209[.]82[.]225' "$dir/extension.js"
    result=$?
    case "$result" in
      0) printf 'ALERT: published marker found in extension.js\n' ;;
      1) printf 'Published text markers not found in this file\n' ;;
      *) printf 'UNRESOLVED: could not inspect extension.js\n' ;;
    esac
  fi
done
BASH

Inspect the actual package.json if the version extraction fails. No output means no matching directory was found in the searched layout; it does not exclude previous installation or a custom path. Finding a published marker in an installed extension is strong evidence requiring containment and investigation.

2. Inspect SSH authorized keys

Cursor's quick check prints a message suggesting an unaffected machine when its grep does not find the comment. That wording is too broad for a full investigation: a missing or unreadable file, another account, prior removal, or a changed comment can defeat that one check.

This alternative searches both the comment and the published public-key material and distinguishes errors from a negative match:

bash <<'BASH'
key_file="$HOME/.ssh/authorized_keys"
if [ ! -e "$key_file" ]; then
  printf 'No authorized_keys file at this path; continue other checks\n'
elif [ ! -r "$key_file" ]; then
  printf 'UNRESOLVED: authorized_keys is not readable\n'
else
  grep -nF \
    -e 'svc-telemetry' \
    -e 'AAAAC3NzaC1lZDI1NTE5AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P' \
    "$key_file"
  result=$?
  case "$result" in
    0) printf 'ALERT: investigate the matching key material\n' ;;
    1) printf 'No published key indicator in this file; continue checks\n' ;;
    *) printf 'UNRESOLVED: key search failed\n' ;;
  esac
fi
BASH

Check other accounts and any non-default AuthorizedKeysFile locations configured by your organization. Do not remove legitimate SSH keys wholesale. Cursor's scripts note that the malicious key can be appended without a preceding newline, potentially sharing a line with an existing key.

3. Inspect the LaunchAgent and dropped files

bash <<'BASH'
agent="$HOME/Library/LaunchAgents/com.apple.sysmond.plist"
if [ -e "$agent" ]; then
  ls -l "$agent"
  plutil -p "$agent"
fi
launchctl print "gui/$(id -u)/com.apple.sysmond"
launchctl print "user/$(id -u)/com.apple.sysmond"

shopt -s nullglob
for file in "$HOME/.config/.smt" "$HOME/.config/.smtk"; do
  [ ! -e "$file" ] || ls -l "$file"
done
user_temp=$(getconf DARWIN_USER_TEMP_DIR)
for directory in "${TMPDIR:-/tmp}" "${user_temp:-/tmp}" /tmp; do
  [ -d "$directory" ] || continue
  find "$directory" -type f -name '.stk_*' -print
done
BASH

A launchd “service not found” result applies to that domain and label only. Inspect a found plist's executable and arguments as text; do not run its referenced script. The published temporary-file pattern is .stk_ followed by ten hexadecimal characters. A file name by itself needs corroboration with contents, process arguments, or the other indicators.

4. Inspect processes, connections, and the SSH listener

ps axww -o pid,ppid,user,command | \
  grep -E '[s]vc-telemetry|134[.]209[.]82[.]225|/\.config/\.smt|/\.stk_[0-9a-f]{10}|[a]utossh|[s]sh .*-[^ ]*R'

lsof -nP -iTCP@134.209.82.225
lsof -nP -iTCP:8099
lsof -nP -iTCP:22 -sTCP:LISTEN

Ordinary SSH and autossh activity can be legitimate. Correlate destination, command line, parent process, key-file path, and persistence. Some processes require an administrator or endpoint agent to inspect fully. A local port-22 listener deserves review, but is not proof of malicious access.

Cursor's server takedown means no present connection is expected to prove much about the past. Search historical firewall, proxy, DNS, and endpoint records for the relevant interval and subsequent execution attempts. Do not contact the attacker IP to test availability.

Windows Checks

Open PowerShell as Administrator for complete profile, process, task, and protected-key visibility. Keep the following checks in the same session because later examples reuse $profilePaths. An account or path you cannot inspect remains unresolved.

1. Inspect extension versions and contents

$profilePaths = @($env:USERPROFILE) + @(
    Get-CimInstance Win32_UserProfile -ErrorAction Stop |
        Select-Object -ExpandProperty LocalPath
)
$profilePaths = @($profilePaths | Where-Object { $_ } | Sort-Object -Unique)

foreach ($profilePath in $profilePaths) {
    $extensionRoots = @(
        (Join-Path $profilePath '.cursor\extensions')
        (Join-Path $profilePath '.vscode\extensions')
    )
    foreach ($root in $extensionRoots) {
        if (-not (Test-Path -LiteralPath $root)) { continue }
        Get-ChildItem -LiteralPath $root -Directory -Force |
            Where-Object Name -like 'anthropic.claude-code-*' |
            ForEach-Object {
                $directory = $_.FullName
                Write-Output "Extension directory: $directory"
                try {
                    $manifest = Get-Content -LiteralPath (
                        Join-Path $directory 'package.json'
                    ) -Raw -ErrorAction Stop | ConvertFrom-Json
                    Write-Output "Manifest version: $($manifest.version)"
                    $bundle = Join-Path $directory 'extension.js'
                    if (Test-Path -LiteralPath $bundle) {
                        $hit = Select-String -LiteralPath $bundle `
                            -Pattern 'svc-telemetry','134.209.82.225' `
                            -SimpleMatch -Quiet -ErrorAction Stop
                        Write-Output "Published text marker present: $hit"
                    }
                } catch {
                    Write-Warning "UNRESOLVED: $directory : $_"
                }
            }
    }
}

Add custom extension directories and other editor installations to the inventory. A negative result covers only the files that still exist and were readable. Review installation history separately, especially if the extension has already been updated or removed.

2. Inspect user and administrator SSH key files

Microsoft's OpenSSH configuration documentation explains that Windows OpenSSH normally uses a user's .ssh\authorized_keys, but administrator-group accounts use the shared %ProgramData%\ssh\administrators_authorized_keys location under the default configuration. Both matter.

$keyPaths = @(
    $profilePaths | ForEach-Object { Join-Path $_ '.ssh\authorized_keys' }
) + @(
    (Join-Path $env:ProgramData 'ssh\administrators_authorized_keys')
)

foreach ($path in ($keyPaths | Sort-Object -Unique)) {
    try {
        if (-not (Test-Path -LiteralPath $path -ErrorAction Stop)) {
            Write-Output "Absent at checked path: $path"
            continue
        }
        $hits = @(Select-String -LiteralPath $path -SimpleMatch `
            -Pattern 'svc-telemetry',
                'AAAAC3NzaC1lZDI1NTE5AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P' `
            -ErrorAction Stop)
        if ($hits.Count -gt 0) {
            $hits | Select-Object Path, LineNumber, Line
            Write-Warning "Published key indicator found: $path"
        } else {
            Write-Output "No published key indicator in: $path"
        }
    } catch {
        Write-Warning "UNRESOLVED: $path : $_"
    }
}

Custom SSH configurations can select additional paths. Text searching is a triage step; unusual file encodings or malformed, concatenated key entries may require byte-level inspection. Never paste the attacker's public key into an authorized-keys file as part of a test.

3. Inspect Scheduled Tasks, Startup entries, and dropped files

Get-ScheduledTask -ErrorAction Stop | Where-Object {
    $_.TaskName -eq 'SysMon' -or
    (($_.Actions | ConvertTo-Json -Compress -Depth 5) -match
        'smt\.cmd|sysmon\.cmd|134\.209\.82\.225')
} | ForEach-Object {
    $_ | Select-Object TaskPath, TaskName, State
    $_.Actions | Format-List Execute, Arguments, WorkingDirectory
    $_.Principal | Format-List UserId, RunLevel, LogonType
}

foreach ($profilePath in $profilePaths) {
    $paths = @(
        (Join-Path $profilePath '.config\smt.cmd')
        (Join-Path $profilePath '.config\smtk')
        (Join-Path $profilePath 'AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd')
    )
    foreach ($path in $paths) {
        if (Test-Path -LiteralPath $path) {
            Get-Item -LiteralPath $path -Force |
                Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtc
        }
    }
    $tempRoot = Join-Path $profilePath 'AppData\Local\Temp'
    if (Test-Path -LiteralPath $tempRoot) {
        Get-ChildItem -LiteralPath $tempRoot -Filter '.stk_*' `
            -File -Force -Recurse -Depth 1 |
            Select-Object FullName, Length, LastWriteTimeUtc
    }
}

The official cleanup script specifically targets a root-level \SysMon task whose action arguments reference .config\smt.cmd. A name match alone is insufficient to distinguish this artifact from legitimate monitoring software. Preserve suspicious task XML and inspect action paths before removing anything. Check any redirected %TEMP% or %APPDATA% locations as well; the example uses conventional profile paths and the per-session temp layout covered by Cursor's script.

4. Inspect processes, connections, and SSH service state

Get-CimInstance Win32_Process -ErrorAction Stop | Where-Object {
    $_.CommandLine -match
        '134\.209\.82\.225|svc-telemetry|\\\.stk_[0-9a-f]{10}|\\\.config\\smt(k|\.cmd)|\\Startup\\sysmon\.cmd' -or
    $_.Name -match '^(ssh|autossh)\.exe$'
} | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine |
    Format-List

Get-NetTCPConnection | Where-Object {
    $_.RemoteAddress -eq '134.209.82.225' -or
    $_.RemotePort -eq 8099 -or $_.LocalPort -eq 8099 -or
    ($_.LocalPort -eq 22 -and $_.State -eq 'Listen')
} | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort,
    State, OwningProcess

Get-Service -Name sshd -ErrorAction Continue

Match OwningProcess with the process inventory. If a process command line is unavailable, use endpoint telemetry or a qualified responder rather than treating the empty field as benign. A missing SSH service, a stopped service, and a service-inspection error are different outcomes.

For historical review, examine Task Scheduler operational events, OpenSSH events where available, PowerShell logs, and endpoint/network records. Logging must already have been enabled to reconstruct past activity; enabling it now does not recreate missing evidence.

Published Indicators of Compromise

The following indicators come from Cursor's notice. Addresses are defanged here to prevent accidental navigation. Use the literal address only in local searches, security controls, and telemetry queries.

Cursor also lists reverse-forwarding arguments such as ssh -N -R '*:0:localhost:22', autossh -M 0, and SSH options that disable normal host-key checking. These strings are search indicators, not commands to execute. Legitimate SSH administration may use some of the same options.

Public-IP lookups to ifconfig[.]me and api[.]ipify[.]org are not independently malicious; Cursor explicitly identifies them as legitimate services. Do not classify a host as infected merely because it contacted one of them.

Malicious VSIX package hashes

These are VSIX archive hashes, not hashes of extension.js, installed directories, or the remediation scripts. For a preserved archive, replace the example path with its real location:

shasum -a 256 '/path/to/preserved-extension.vsix'

Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\Evidence\preserved-extension.vsix'

A match identifies the published malicious archive. A mismatch does not clear an endpoint: the preserved file could be another build, a repackaged archive, or a replacement downloaded after the event.

Safe Cleanup Using Cursor's Official Scripts

Use the scripts currently linked from the official advisory. The steps below refer to the versions reviewed on October 31, 2026; revisit the notice for changes. They should be reviewed by your security team before use on a managed endpoint.

macOS remediation

After containment, evidence preservation, and closing editors, download Cursor's macOS remediation script on a trusted machine. If downloading locally is appropriate, the command is:

curl --fail --location --proto '=https' --proto-redir '=https' \
  --tlsv1.2 \
  'https://cursor.com/static/security/claude-code-extension/remediate-macos.sh' \
  --output remediate-macos.sh

Review the downloaded file and its source URL. Run it as the affected user, without sudo:

bash remediate-macos.sh
cleanup_status=$?
printf 'Cleanup exit status: %s\n' "$cleanup_status"

The official macOS script attempts to unload the known launchd job, stop matching tunnel processes, remove extension directories whose extension.js contains the marker, delete the known dropped files, and remove the exact attacker key while preserving the rest of authorized_keys.

It searches the conventional hidden-home-directory extension layout. Repeat as each affected user; custom locations still need review.

Windows remediation

Download Cursor's Windows remediation script from the advisory on a trusted system. Review it, transfer it if required, close editors, and open PowerShell with Run as Administrator in the folder containing the file:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\remediate-windows.ps1
$cleanupExit = $LASTEXITCODE
Write-Output "Cleanup exit status: $cleanupExit"

This applies the execution-policy setting to the launched PowerShell process. It is not an instruction to permanently weaken system policy or bypass organizational application controls. If security policy blocks the reviewed script, involve the administrator responsible for that policy.

The script enumerates Windows user profiles, removes the matching \SysMon task, stops processes matching its artifact patterns, removes marked extension folders and dropped files, and removes the exact attacker key from per-user authorized_keys.

Important coverage limits to verify afterward

The Windows quick check and cleanup script do not cover exactly the same key locations. The advisory's quick check includes C:\ProgramData\ssh\administrators_authorized_keys. In the script reviewed for this guide, key removal is performed inside the user-profile loop against each profile's .ssh\authorized_keys; there is no corresponding shared-administrator-file cleanup step.

If the shared administrator file contains the published malicious key, preserve a restricted copy and have an administrator remove that exact unauthorized key material while retaining legitimate keys, encoding, ownership, and ACLs. Then rerun the check.

Avoid deleting the entire file or deleting every line containing a comment: the payload may have appended its key directly to a legitimate key's line. The same caution applies to custom authorized-key paths or a modified key comment that defeats the scripts' exact-string matching.

Neither reviewed script is a general-purpose incident-response tool. They do not rotate credentials, reconstruct historical attacker activity, or establish that the host contains no other payloads. They also do not automatically return an enabled SSH service to the organization's pre-incident configuration. Review whether SSH should be enabled and restrict or disable it through approved administration without interrupting legitimate remote access.

Treat a nonzero exit status or any warning as unresolved remediation. Treat zero as completion of the script's checks, not independent proof of a clean machine. The advisory describes failure reporting, but a script can only detect the paths, patterns, errors, and processes that it actually checks. Independently repeat the wider checks in this guide.

Credential Rotation and Account Review

Cursor recommends rotating credentials and sessions accessible from affected hosts, using a trusted system. That is a precaution based on possible follow-on access, not a claim that every secret was stolen.

For a host with execution or persistence evidence, prioritize credentials the affected account could read or use:

Do not sign in to sensitive accounts on a potentially compromised host to perform the rotation. Revoke old credentials server-side; editing a local .env file does not invalidate the original secret.

The attacker public key added to authorized_keys is separate from your own outbound SSH private keys, so removing it does not address possible exposure of those private keys.

These credential categories are investigation priorities, not additional exfiltration behaviors confirmed by Cursor. Use asset ownership and access records to determine the actual scope. For a device with only a version-number match and no established exposure, investigate provenance before declaring an organization-wide credential breach.

Verify Recovery and Decide Whether to Rebuild

Keep the host contained while completing these checks. Preserve evidence before a reboot; rebooting destroys volatile process state and can activate remaining persistence.

1. Repeat the file and key checks. Check all relevant users, the Windows shared administrator file, and custom locations. Resolve permission errors.
2. Repeat persistence checks. Confirm the malicious launchd job, task actions, Startup entry, and referenced scripts are gone. Merely disabling an extension does not satisfy this step.
3. Review running processes and listeners. Verify that matching tunnel processes have stopped and any SSH service configuration matches the approved baseline.
4. Reboot under controlled conditions, then check again. Look for recreated artifacts or processes and review endpoint alerts. A quiet moment before the next retry is insufficient.
5. Search historical telemetry and run endpoint security scans. Investigate successful SSH logins, unusual descendants of editor processes, and subsequent account activity. A negative scan supplements the investigation; it does not replace it.
6. Confirm revocation and account review. Verify that old credentials no longer work, active sessions were invalidated where appropriate, and no unauthorized account or repository changes remain.
7. Restore extensions from a verified source after recovery. Check publisher and registry provenance. Do not restore the suspect VSIX or blindly copy the previous extensions directory from backup.

Rebuild from trusted installation media when confidence cannot be restored, especially if there is evidence of successful unauthorized access, unexplained privileged activity, additional payloads, returning persistence, or an important telemetry gap on a sensitive host.

Cursor explicitly recommends assessing whether affected hosts should be rebuilt. A rebuild should use reviewed data backups and fresh credentials rather than restoring executable persistence from the compromised environment.

For team prevention, Cursor currently documents marketplace install cooldowns, extension allowlists, and enterprise signature-verification controls. Review those options alongside least-privilege editor execution and endpoint visibility. Do not assume that a publisher badge, a signature, or a fixed delay alone makes an extension safe.

FAQ

Does having Claude Code 2.1.313 mean a device is infected?

No. Cursor's scripts explicitly account for the malicious package retaining the version number. Investigate the distribution source, installation window, archive hash where available, extension contents, and execution artifacts. A version match establishes a reason to check, not a complete diagnosis.

Was the official Claude Code extension developed by Anthropic malicious?

Cursor says the malicious version was not developed by Anthropic and reports no evidence that the official distribution or other versions were affected. Keep that attribution distinct from the modified package distributed through Cursor.

Did Microsoft VS Code Marketplace or Open VSX get hacked?

The Cursor advisory does not establish either claim. Cursor's current documentation describes Open VSX as an upstream registry behind its own marketplace proxy. That architectural relationship does not identify where or how the package was tampered with.

Is uninstalling the extension enough?

No. Cursor identifies standalone persistence scripts, unauthorized SSH keys, and tunnel processes. Use the official cleanup script and verify the wider set of artifacts afterward.

Can the initial SSH-key check prove that a machine is safe?

No. A positive match is actionable evidence, but a negative match covers only the searched file and indicator. Other accounts, unreadable files, prior cleanup, changed markers, and non-default paths require additional investigation.

Is a device safe because Cursor did not run as administrator?

That reduced the ability of the documented payload to establish remote SSH access, according to Cursor. It does not exclude host-detail reporting, key insertion, or user-level persistence. Complete the checks and assess actual execution evidence.

Should an infected device still be cleaned if the attacker server is offline?

Yes. Takedown interrupts that infrastructure but leaves local persistence, key changes, and possible prior exposure unresolved. Do not reconnect to or probe the endpoint to verify the takedown yourself.

Is there a confirmed safe replacement version number?

The cited notice does not name a replacement version that can serve as a universal remediation answer. It reports that the marketplace was rebuilt and restored. Clean the endpoint first, then obtain a legitimate extension through a verified distribution path; merely installing a different version does not remove standalone persistence.

Does the notice prove API keys or source code were stolen?

No. It confirms host-information collection and attempts at persistent access. It distinguishes environment-variable names from values. Credential rotation is justified by potential follow-on access, and actual theft must be assessed through additional evidence.

Conclusion

The Cursor Claude Code incident requires attention to both extension provenance and operating-system persistence. The decisive checks go beyond an extension version: inspect the published key material, LaunchAgent or Scheduled Task, dropped scripts, tunnel processes, and historical connections.

For affected machines, preserve evidence, contain execution, run Cursor's current platform-specific remediation script, close its coverage gaps, and rotate accessible credentials from a trusted system. Recheck after a controlled restart and rebuild when the evidence does not support restoring trust. Start with Cursor's live advisory, which may be updated as the investigation develops.