Into the Expanse: A Security Leader’s Guide to the Agent Frontier
Read more
Get a demo
Demo Request
Take a personalized product tour with a member of our team to see how we can help make your existing security teams and tools more effective within minutes.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Home
Blog

A Backdoored Extension Is an Endpoint Problem Until It Touches Your Apps

Gilad Israeli Shilon
Updated
November 5, 2026
November 5, 2026
10 min read
Ready to Close the SaaS Security Gap?
Chat with us

On October 29, 2026, a tampered copy of the Claude Code extension (anthropic.claude-code, versions 2.1.312 and 2.1.313) was served on the Cursor extension marketplace for roughly 11 hours, from about 2:27 a.m. to 1:35 p.m. PDT. Microsoft analyzed it and published the details on October 30. Anthropic says its own systems were not compromised, and the package was never on the Visual Studio Marketplace or npm.

‍

The attack starts on a laptop. Where it matters is everything that laptop is connected to: the developer's SaaS accounts, cloud keys, and the agents and tools that act on their behalf. 

‍

Here's how the attack works, what we found when we hunted for it, how this kind of attack reaches agents and SaaS, and what to do right now.

‍

What Happened

An extension is code that runs with the privileges of whoever installed it. In this case, the code was a loader injected ahead of the extension's normal code, so the extension kept working and nothing looked wrong.

‍

According to Microsoft's analysis, the loader:

‍

  • Collects host details. Hostname, username, OS, home directory and the global git email, plus the names (not the values) of environment variables that look like keys, tokens or secrets.

  • Plants an SSH key. It adds an attacker key, commented svc-telemetry, to the user's authorized_keys and tries to turn on the local SSH service.

  • Opens a reverse tunnel. The workstation connects out to the attacker's server (134.209.82.225) and asks it to forward connections back to the workstation's SSH port. Because the connection starts from inside, no inbound firewall rule is needed.

  • Persists under system-sounding names. A LaunchAgent called com.apple.sysmond.plist on macOS and a scheduled task called SysMon on Windows. The code also contains a Linux crontab path, but Cursor's notice covers only the macOS and Windows builds.

  • Reports home. A delayed callback sends the collected details to the attacker. Cursor's notice adds that the public IP address is included.

Cursor reports that turning on the local SSH service requires administrator rights, which the extension does not have on most macOS and Windows hosts, so on those hosts the attacker could not have logged in through the tunnel. The key, the persistence and the beacon could still be planted, and none of it goes away when the extension is removed. Cursor also says it worked with the hosting provider to take the attacker's server offline. That stops new connections. It does not remove anything already on a machine.

‍

What We Found

We searched for the published attacker IP, the persistence files and the reverse-SSH command line. Reco ingests alerts from the endpoint security tools our customers already run, so we could check those alerts, AI-agent activity and SaaS sign-ins together.

‍

We found the activity in multiple customer environments, as endpoint alerts on individual Macs on October 29, inside the exposure window. We then checked the SaaS environments for follow-on offensive activity: the attacker's IP, new keys or tokens, and unfamiliar sign-ins. To date, we have found no evidence of it.

‍

How a Backdoor on a Laptop Reaches Agents and SaaS

We want to be precise about what is shown and what is inferred. Microsoft's analysis shows the foothold: key, tunnel, persistence, beacon. It does not show credentials being stolen from any machine. What follows is the well-documented path from this kind of foothold to agent and SaaS access, and the reason we treat every affected machine as a lead.

‍

How likely is this, in this incident?

Let’s be realistic. According to Cursor, the tunnel step fails except in unusual cases where Cursor was started with administrator privileges, and the attacker's server is now offline. For most affected machines, this incident most likely stays an endpoint problem. We still treat every affected machine as a lead. The beacon told the attacker which machines loaded the extension, with the user and public IP on each, while the server was up. The planted key and persistence stay until someone removes them. And Cursor itself advises rotating credentials, noting that the limited collection of variable names does not rule out later credential access over the backdoor.

‍

So the useful question is less "did this extension reach SaaS" and more "what does this pattern look like when it does."

‍

1. The foothold runs as the user

The loader executes inside the editor's extension host, with Node.js APIs and the user's own file permissions. If the reverse tunnel works, the SSH key gives an attacker an interactive session as that user. Even without the tunnel, code running in that process can read what the user can read. The analyzed sample does not do that beyond collecting variable names, but a different payload in the same position could.

‍

2. A developer machine now holds the keys to your SaaS, your cloud and your agents

The loader's own reconnaissance shows what the attacker is looking for: environment variables containing KEY, TOKEN, SECRET, PASS, AWS or GCP. Developer machines typically also hold GitHub tokens and SSH keys, cloud CLI credentials, and AI platform API keys. Google Threat Intelligence Group (GTIG) lists "developer workstation and IDE compromise", including malicious IDE extensions designed to exfiltrate private keys, API tokens and local session credentials, as a scenario defenders should have a response playbook for. [1]

‍

Not everything is equally easy to take. Secrets in plain-text files and environment variables are trivial to read. Secrets in an OS keychain or on a hardware key are harder. That difference is the biggest factor in how bad a given machine's exposure is.

‍

3. Agents raise the stakes

The package was a tampered copy of a real AI coding extension, so the machines that ran it are exactly the machines that hold agent credentials. A machine running AI coding tools holds more than the developer's own credentials:

‍

  • The agent's own connections. Agents and assistants are non-human identities with their own API keys, OAuth grants and MCP server configurations, which often embed tokens. Those connections reach GitHub, Slack, ticketing systems and cloud services. A compromised machine exposes the agent's access along with the person's.

  • The agent as an executor. Coding agents run shell commands, edit repositories and call tools with the developer's permissions. Code running in the same user context inherits that reach without needing another exploit. This is our inference about the position, not something reported for this sample.

  • The agent supply chain is itself a target. GTIG reports threat actors inserting malicious code into open source MCP packages, planting malicious resources in open source AI communities, and publishing packages that tricked AI coding agents into adopting them. [1] It also reports that in incident response engagements, the actor behind the 2026 TeamPCP campaigns attempted to pivot from compromised AI software to broader network environments, and monetized stolen credentials by selling them or through partnerships with extortion groups. [1]

The result is that a single compromised developer machine can expose a person, the agents acting for that person, and every SaaS and cloud system both can reach.

‍

4. How those credentials turn into SaaS access

Three mechanisms, all documented in past campaigns:

‍

  • Stolen credentials used from outside. Mandiant tracked UNC5537 compromising Snowflake customer instances using credentials stolen by infostealer malware on endpoints, including contractor laptops. The accounts lacked MFA and network allow-lists, so a valid credential from anywhere was enough. [2] Different malware, same path: endpoint to credential to SaaS data.

  • Tokens that never get an SSO challenge. GTIG notes that SAML SSO in front of GitHub verifies identity when a personal access token or SSH key is created or authorized, but cannot challenge the session state of programmatic CLI connections afterward. A stolen token or key works from the attacker's infrastructure with no fresh login. [1] Microsoft's incident responders describe the same shape for cloud sessions: replaying a token issued to an identity that already completed MFA satisfies the MFA check, and the expertise needed is low. [3]

  • Operating from the user's own device. With a reverse tunnel, an attacker can work from the victim's real machine, so traffic carries the real device's network position. This is our inference from how the tunnel works, not something Microsoft reports for this sample. It matches well-documented tradecraft: Mandiant observed UNC3944 (Scattered Spider) using tunneling utilities such as ngrok on virtual machines it had created, to reach them without a VPN or MFA, and separately using stolen credentials to pivot into SaaS applications behind SSO. [4] Microsoft tracks the same group as Octo Tempest and also lists tunneling tools in its tradecraft. [5]

5. What it looks like on the SaaS side

These are ordinary audit-log events, and they are the earliest evidence that an endpoint foothold has become a SaaS compromise:

‍

  • New SSH keys, deploy keys or personal access tokens created for a user on an affected machine.

  • Sign-ins or API calls using that user's or an agent's tokens from unfamiliar locations, hosting-provider addresses or devices. GTIG's own guidance is to track authentication on long-lived static keys from unrecognized IPs. [1]

  • MFA method re-registration. Mandiant recommends monitoring it. [6]

  • New OAuth app grants, new cloud access keys, and bulk repository clones or data exports.

What to Do Right Now

Work through these in order. Each is independent, so do all of them.

1. Find affected machines

Check which Mac and Windows machines installed or auto-updated anthropic.claude-code 2.1.312 or 2.1.313 from the Cursor marketplace on October 29, 2026, between about 2:27 AM and 1:35 PM Pacific. Cursor's security notice includes a one-line check for the planted key, and recommends searching endpoint, network and extension-installation telemetry for the published indicators. The notice covers macOS and Windows. The key check is the fastest test, but a missing key is not an all-clear: the loader swallows errors, so the persistence can exist without the key. Follow it with the checks in step 2.

2. Look for leftovers

  • Check ~/.ssh/authorized_keys for an entry commented svc-telemetry. On Windows, also check C:\ProgramData\ssh\administrators_authorized_keys.

  • On macOS, look for ~/Library/LaunchAgents/com.apple.sysmond.plist, ~/.config/.smt and ~/.config/.smtk.

  • On Windows, look for a SysMon scheduled task and sysmon.cmd in the Startup folder.

  • Do not remove an item on its name alone. The names are chosen to look like system components, and a legitimate Sysmon install exists in many environments. Read the task or LaunchAgent action first and confirm it runs the attacker's script (.smt or smt.cmd).

  • Search network logs for 134.209.82[.]225.

Microsoft's write-up lists every path and the hunting queries.

3. Clean up and rotate

Isolate the machine first and keep evidence. Remove the key, the startup entries and the scripts separately from the extension. Cursor publishes remediation scripts for macOS and Windows that do this and exit with an error if anything remains; read them before you run them. Then rotate that person's credentials and tokens from a clean device. Prioritize GitHub tokens and SSH keys, cloud access keys, and AI platform and agent API keys, including any tokens in MCP configurations.

4. Check what those credentials did

For each affected person, review recent activity in your SaaS and cloud systems for the signals in section 5, including activity by the agents they run. Treat anything that began on or after October 29 as a lead.

5. Limit future exposure

In Cursor, restrict extensions to approved publishers or extension IDs (in the team dashboard or with the AllowedExtensions MDM policy), and set the Marketplace Install Cooldown under Team settings, Security & automation. The cooldown is off by default, and when set it applies fleet-wide and overrides individual settings. Microsoft's write-up recommends both. Cursor's guidance is at https://cursor.com/docs/enterprise/security-hardening and https://cursor.com/help/customization/extensions. Shorten the lifetime of personal access tokens and API keys, require MFA everywhere, and restrict SaaS access to trusted network locations where you can. The Snowflake campaign succeeded on exactly those three gaps. [2]

The Bottom Line

  • A trusted publisher name is not a security control. Control who can publish and what installs automatically.

  • A developer laptop is a bundle of credentials, and now also a bundle of agents. The endpoint is where the attack starts, and your SaaS and cloud accounts are where it pays off.

  • Isolating a host or removing an extension is not cleanup. Check for the key, the startup items and the scripts.

  • After any developer-tool incident, review SaaS, cloud and agent activity for the affected people, not only endpoint telemetry.

‍

References

1. Google Cloud Blog (GTIG and Mandiant), "Mitigation Guidance for Supply Chain Compromise," July 30, 2026. https://cloud.google.com/blog/topics/threat-intelligence/mitigation-guidance-for-supply-chain-compromise/

2. Google Cloud Blog (Mandiant), "UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion." https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion

3. Microsoft Security Blog, "Token tactics: How to prevent, detect, and respond to cloud token theft," Nov 16, 2022. https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/

4. Google Cloud Blog (Mandiant), "UNC3944 Targets SaaS Applications." https://cloud.google.com/blog/topics/threat-intelligence/unc3944-targets-saas-applications

5. Microsoft Security Blog, "Protecting customers from Octo Tempest attacks across multiple industries," July 16, 2025. https://www.microsoft.com/en-us/security/blog/2025/07/16/protecting-customers-from-octo-tempest-attacks-across-multiple-industries/

6. Google Cloud Blog (Mandiant), "Defending Against UNC3944: Cybercrime Hardening Guidance from the Frontlines." https://cloud.google.com/blog/topics/threat-intelligence/unc3944-proactive-hardening-recommendations

7. Microsoft Security Research, "Inside a malicious Claude Code-branded extension and its persistent SSH backdoor," Oct 30, 2026. https://www.microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

8. Cursor, security notice for the malicious anthropic.claude-code versions. https://cursor.com/blog/claude-code-extension-security-notice

9. Cursor docs, "Security and Privacy Hardening" and "Extensions". https://cursor.com/docs/enterprise/security-hardening and https://cursor.com/help/customization/extensions

No items found.

Gilad Israeli Shilon

ABOUT THE AUTHOR

Technical Review by:
Gal Nakash
Technical Review by:
Gilad Israeli Shilon

Table of Contents
Let’s Talk About Your Non-Human Users
Chat with us
Get the Latest SaaS Security Insights
Subscribe to receive updates on the latest cyber security attacks and trends in SaaS Security.

Be the team that enabled agents without losing control.

Want to look around first? Take a platform tour →