Software Supply Chain Security Starts in Your Developers' Editor

On October 29, a trojanized build of the Claude Code extension (version 2.1.313) sat in Cursor's extension marketplace for about 11 hours. It shipped under the real publisher name, not a lookalike, and it quietly planted an SSH backdoor on developer machines. Cursor says up to 5,000 users may have installed it.

If you run a business that pays developers or contractors, this is a software supply chain security problem that lands on your desk, not just theirs. Most supply chain advice focuses on packages and build servers. This one walked in through the code editor.

TL;DR#

• A malicious update to a widely used AI coding extension was published under the legitimate publisher identity and auto-installed for some Cursor users on October 29, 2026.
• The payload added an attacker SSH key, opened a reverse tunnel, set up persistence and sent back machine details, including the names of secret-looking environment variables.
• Treat editor extensions like any other third-party dependency: inventory them, pin versions, delay auto-updates and keep production secrets off laptops.

What happened with the Claude Code extension#

According to StepSecurity's timeline, the malicious 2.1.313 build went live around 09:27 UTC on October 29 and was pulled at 20:35 UTC, when Cursor removed it and briefly took its marketplace offline. A clean 2.1.314 followed early on October 30.

The build was the real extension with a small loader added to the main JavaScript bundle. OpenSourceMalware's Jenn Gile described it to The Hacker News as a 66-line loader inserted before the legitimate code. When the editor loaded the extension, the loader:

1. Added an SSH public key labelled svc-telemetry to the user's authorized_keys file.
2. Tried to switch on the local SSH server (this usually fails without admin rights, per Cursor).
3. Opened a reverse SSH tunnel to an attacker server.
4. Installed persistence: a LaunchAgent on macOS, a scheduled task on Windows, a cron entry on Linux.
5. Beaconed hostname, username, OS, git email and the names of up to 40 environment variables matching patterns like KEY, TOKEN and SECRET.

How the build got published is still open. Morphisec and The Hacker News both say the root cause hasn't been publicly established, and sources disagree on whether Open VSX itself carried the bad version or only Cursor's mirror did.

Why software supply chain security now includes the IDE#

Editor extensions run with the same permissions as the developer. They can read the repo, the shell environment, SSH keys and cloud credential files. There's no sandbox prompt like the one your phone shows before an app reads your contacts.

That's what made this incident nasty. Nobody had to click a phishing link. Anyone with auto-update on simply received a new version of a tool they already trusted. The publisher name was correct, so the usual "check you've got the official extension" advice did nothing.

AI coding extensions raise the stakes further. They're installed on exactly the machines that hold the most access, they update often, and teams adopt them fast because they're useful. A popular AI extension is a better target than a random theme pack.

There's also a business angle that's easy to miss. If you rely on an agency or freelancers, their laptops are part of your supply chain too. A compromised contractor machine with a long-lived token to your Shopify store, Stripe account or production database is your incident, whoever's name is on the hardware.

Technical breakdown: where the trust breaks#

Here's the simplified path a malicious extension update takes:

Publisher account / build ──► Registry (Open VSX, VS Code Marketplace)
                                     │
                                     ▼
                         Editor marketplace mirror
                                     │  auto-update
                                     ▼
              Developer laptop: repo, SSH keys, .env, cloud CLI tokens
                                     │
                                     ▼
              Attacker: reverse tunnel + beacon with machine details

Every arrow is a place you can add a check. The trade-off is friction, so it helps to compare controls honestly:

The allowlist alone wouldn't have helped here, because the bad build carried the right name. What would have helped is a simple delay. The malicious version was public for roughly 11 hours. A team that only accepts extension updates after a few days would have skipped it entirely.

What it means for businesses#

If your developers use Cursor and had the Claude Code extension installed with auto-update on during the window, assume exposure until you've checked. Remediation guidance from StepSecurity, Morphisec and ThreatDefence lines up on the key points:

• Uninstalling the extension isn't enough. The persistence lives outside the extension folder.
• Check ~/.ssh/authorized_keys for a key labelled svc-telemetry.
• Remove the LaunchAgent, scheduled task or cron entry and the dropped files.
• Rotate any credential reachable from that machine, from a clean device: git hosting, CI/CD, cloud, SSH and package registry tokens.
• If the tunnel connected, rebuild the machine.

The bigger lesson is about your defaults. Most small teams have no idea which extensions are installed across their developers' machines. That's the same blind spot companies had with npm packages five years ago, and the CISA guidance on securing the software supply chain already asks customers to know what third-party software they run.

How to tighten software supply chain security this week#

You don't need a security team to make real progress. Work through this list in order:

1. Inventory. Ask every developer and contractor to export their extension list (code --list-extensions --show-versions works in VS Code and most forks). Put it in one sheet.
2. Cut the list. Remove anything unused. Each extension is code running with full user rights.
3. Turn off silent auto-update for extensions on work machines, and update on a schedule after a short delay.
4. Move secrets off laptops. Use SSO, short-lived cloud credentials and a secrets manager. Production keys in a local .env file are the real prize for an attacker.
5. Watch for the obvious. New entries in authorized_keys, new LaunchAgents and new scheduled tasks are cheap to alert on.
6. Write contractor rules into contracts. Require named, scoped access for agencies and freelancers, and revoke it when the work ends.
7. Rehearse rotation. If you can't rotate your Stripe or database credentials in an hour, practise until you can.

How MagicMakers Lab approaches this#

When we build custom software or agentic systems for clients, such as the platform that consolidated three disconnected systems for Business Hub, we treat developer tooling as part of the attack surface from day one. Production credentials never live on engineers' laptops, access is scoped per project and revoked at handover, and integrations with tools like Shopify and Stripe use short-lived, least-privilege tokens. On projects like Framico, where orders ship with zero manual steps, that discipline is what keeps automation from turning into a single point of failure.

Key takeaways#

• The trojanized Claude Code extension shipped under the real publisher name, so name checks alone don't protect you.
• Editor extensions run with full developer permissions, making them a real software supply chain security risk.
• A short delay before accepting extension updates would have avoided this specific attack.
• Keeping long-lived production secrets off laptops limits the damage of any endpoint compromise.
• Contractors' machines are part of your supply chain, so scope and revoke their access.

FAQ#

What is software supply chain security?#

It's the practice of protecting everything that goes into building and running your software: third-party packages, build systems, registries, developer tools and the accounts that publish them. The goal is to make sure no component, update or tool can slip in malicious code or leak access. For most businesses, the practical starting point is knowing which third-party software you depend on.

Is the Claude Code VS Code extension safe to use now?#

The malicious version was 2.1.313, and clean 2.1.314 was published on October 30, 2026, according to The Hacker News and StepSecurity. Current versions from the official listings aren't reported as compromised. If you had 2.1.313 installed, updating isn't enough: check for the svc-telemetry SSH key and persistence entries, and rotate credentials.

How do I check my VS Code or Cursor extensions for malware?#

Start by listing installed extensions and versions with code --list-extensions --show-versions. Compare them against known-bad versions from security advisories, and remove anything you don't use. Then check for side effects that outlive the extension, like unexpected SSH keys, LaunchAgents, scheduled tasks or cron jobs. Endpoint detection tools can automate most of this.

What are software supply chain security best practices for small teams?#

Keep a list of dependencies and developer tools, pin versions and delay updates by a few days, and use SSO with short-lived credentials instead of long-lived keys. Scope contractor access per project and revoke it at handover. Finally, practise rotating your most important secrets so a compromise means an hour of work, not a week.

If you're not sure what your developers' machines can reach, or whether your integrations rely on long-lived keys, we'll map it with you and show you the quickest fixes. Book a free audit.

Sources#

• The Hacker News: Official Claude Code Extension on Cursor Marketplace Trojanized with Persistent SSH Backdoor
• StepSecurity: Trojanized Claude Code Extension Delivered Persistent SSH Backdoor to Developer Machines
• Morphisec: Trusted Tool, Malicious Build
• ThreatDefence: Trojanized Claude Code Extension on Open VSX
• CISA: Securing the Software Supply Chain, Recommended Practices Guide for Customers