Developer Endpoints Targeted in Cursor Supply Chain Attack

On Oct. 29, Cursor pulled a malicious version of the Claude Code extension from its marketplace. It was live for about 11 hours.

Cursor isn't the first marketplace to face this type of incident. 

In May, a trojanized release of the popular Nx Console extension sat on the VS Code Marketplace for just 18 minutes. That was long enough to reach a GitHub employee's laptop and lead to a breach of GitHub's internal repositories. (CSA research note)

In both incidents, automatic updates helped distribute the malicious extensions. Developers didn't install anything new. Their tools pulled in the bad version on their own, often on the next restart. 

The extension you approved last month isn't necessarily the one running today.

These incidents highlight a recurring weakness in how developer tools are distributed and updated. It's time to look closely at what's coming into your environment.

Why developer endpoints?

A malicious extension is just the way in. What attackers really want is everything a developer's machine can reach.

A typical developer laptop holds:

• Source code: local clones of private repositories
• Credentials: GitHub and npm tokens, SSH keys, and cloud keys
• Secrets: API keys in config files, password manager sessions, and AI agent settings
• Access: live sessions into CI/CD pipelines, production systems, and internal tools

That's why both payloads went after the same things. The Cursor payload tried to plant an SSH key and open a tunnel back to the attacker. The Nx Console payload harvested GitHub, npm, and AWS credentials, plus Claude Code configurations.

Compromising a developer endpoint can give attackers a foothold into other enterprise systems.

And developers install more than most. New extensions, plugins, packages, MCP servers, and AI agents arrive every day, often without a security review.

Image: a developer laptop at the center, with lines fanning out to icons for source code, cloud, CI/CD, and production. Caption idea: "One laptop. Keys to everything."

How Glow Helps: Four Layers of Protection

Glow helps organizations manage software supply chain risk through four complementary controls.

Each layer works on its own. Together, they cover before, during, and after an incident.

1. Official vs. unofficial: steer people to the real thing

Popular tools attract copycats. Marketplaces fill up with lookalike extensions, unofficial forks, and repackaged versions of well-known tools. Distinguishing legitimate third-party extensions from malicious impersonators isn't always straightforward.

Glow uses AI agents to research whether each package, extension, or plugin comes from its official publisher. When an official version exists, you can set policies that steer people to it.

• Spot unofficial versions already in your environment
• Point developers to the official package or plugin
• Cut exposure to impersonation and typosquatting

2. Cool-off periods: give new versions time to prove themselves

A cool-off period holds brand-new versions for a set time before anyone can install them. Existing versions remain available while newly published versions are held for review.

Why it works: The delay creates an opportunity for malicious versions to be identified and removed before installation.

• Nx Console on VS Code: pulled after 18 minutes
• Claude Code on Cursor: pulled after about 11 hours

A cool-off of even a day would have kept both off your developers' machines. Auto-update keeps its benefits. It just stops being instant.

3. Blocking: enforce what is and isn't allowed

The gateway blocks new downloads of anything your company has decided isn't allowed. That includes packages flagged as malicious by Glow Labs or the wider security community. It also includes anything that breaks your own policies, like a banned tool, an unapproved AI agent, or a plugin your team has ruled out.

Centralized policies help enforce these restrictions consistently across managed endpoints.

4. Inventory: see everything that runs

Glow finds every package, extension, and plugin on every endpoint. That includes IDE extensions, browser extensions, AI coding agents, MCP servers, and the libraries they pull in.

When an alert like Cursor's lands, the response becomes a lookup, not a fire drill:

• Which machines have Claude Code 2.1.313?
• Who installed or updated during the exposure window?
• What else is running on those machines?

How the layers work together

• Official-package policies steer people away from lookalikes and unvetted forks.
• Cool-off periods keep unproven versions out.
• Blocking stops versions confirmed to be malicious.
• Inventory finds anywhere a bad version already landed, so you can respond fast.

Image: timeline graphic. A new version is published at hour 0; it's flagged and pulled within hours; the cool-off window extends past that point, so it never reaches the endpoint.

The takeaway

Developer endpoints hold the keys to your code, cloud, and pipelines. And what runs on them changes every day, often without anyone looking.

Banning plugins and extensions isn't the answer. They're how modern teams ship. The answer is knowing what's coming in, and having a say in it:

• Steer people to official versions, not lookalikes.
• Give new versions time to prove themselves before entering your environment.
• Block anything malicious or unapproved everywhere, at once.
• Know every package, extension, and plugin on every endpoint.