Cursor Confirms a Stolen Fireworks Key Let Attackers Ship a Backdoored Claude Code Extension to 5,000 Developers

AI disclosure: This article was drafted with AI assistance and checked against Cursor's incident update of 13 November 2026 and reporting by BleepingComputer (14 November) and The Hacker News (15 November). I have not independently verified the incident — everything technical below is Cursor's account as reported. Nothing here is sponsored, and there are no affiliate links on this page.

Cursor has confirmed the worst kind of supply-chain story: a stolen API key from a third-party breach ended with a backdoored version of Anthropic's official Claude Code extension being served from Cursor's own extension marketplace cache — to as many as 5,000 developers.

The incident update, published by Cursor on Friday 13 November 2026, connects two events that were already bad on their own. First, the Fireworks AI breach that Cursor disclosed on 10 November: an access key Cursor had issued to Fireworks AI was exposed, and the attacker used it to copy a read-only storage bucket of historical coding-agent traces — mostly from 2025, from users who had not enabled Privacy Mode. Some of those traces contained unredacted API credentials. Then, on 29 October, the attacker used one of those stolen credentials to place trojanized copies of the Claude Code extension directly on the cache serving Cursor's extension marketplace.

This is the follow-up to the Fireworks breach story from 10 November. That first disclosure covered the vendor breach. This one is about what the attacker did with it — and it reached into developers' machines.

What happened

The chain of events, as Cursor describes it:

• The key leak. Cursor had issued an access key to Fireworks AI, one of its inference providers. That key was exposed in the Fireworks breach, and the attacker used it to copy a read-only storage bucket holding historical coding-agent traces. The traces were mostly from 2025 and came from users who had not enabled Privacy Mode. Some traces contained API credentials that had not been redacted.
• The weaponisation. On 29 October 2026, the attacker used a credential stolen from that data to put trojanized copies of Anthropic's official Claude Code extension — versions 2.1.312 and 2.1.313 — directly onto the cache that serves Cursor's extension marketplace.
• The exposure window. The malicious builds were live for roughly 11 hours. Up to 5,000 users who requested those cached versions in that window may have received them.
• The payload. The trojanized extensions tried to install a persistent SSH backdoor: LaunchAgents on macOS, cron entries on Linux, and scheduled tasks on Windows. A persistent backdoor is the kind of thing that survives a reboot and a reinstall of the extension — it is designed to stay.

The scale, in Cursor's own numbers: fewer than 0.05% of users had traces exposed, and fewer than 0.01% had API credentials compromised. Small percentages — but Cursor has millions of users, and 5,000 developers potentially running a backdoored extension is not a small number in absolute terms.

What was NOT affected

Cursor is explicit about the boundaries, and they matter:

• Users who had Privacy Mode enabled — their code and prompts were not in the exposed traces.
• Customer code repositories were not affected.
• Cursor's production environment was not affected.
• Official Cursor app updates were not affected — this was the extension marketplace cache, not the app update channel.
• Anthropic's legitimate Claude Code extension was not affected, and neither were the Open VSX Registry or the VS Code Marketplace. The trojanized copies lived only on Cursor's marketplace cache.

That last point is worth underlining, because it's the detail people will get wrong: if you installed Claude Code from VS Code Marketplace or Open VSX, this incident did not touch you. The compromised path was Cursor's own extension marketplace cache.

What Cursor did about it

Cursor says it notified the affected users, revoked and rotated the exposed credentials, deactivated the Fireworks access key, and moved all inference traffic off Fireworks entirely. It also rebuilt the extension marketplace and redeployed its production infrastructure. And it reports no malicious activity detected since 1 November 2026.

Moving all inference traffic off a provider is a drastic step — it tells you how seriously Cursor now treats the Fireworks relationship. Rebuilding the extension marketplace is the other telling move: you don't rebuild a whole distribution path unless you no longer trust the one you had.

What it means for you

If you use Cursor, the honest assessment is this: the blast radius was contained, but the failure mode is the scary part. Nobody's editor was hacked directly. A trusted distribution channel — the marketplace cache your editor quietly pulls extensions from — served a tampered build of a popular, legitimate extension. That's the supply-chain nightmare in miniature: the thing you installed was real, from a source you trusted, and the compromise happened one step upstream, where you couldn't see it.

Two lessons are worth carrying out of this:

1. Your extension marketplace is part of your trust boundary. Most developers treat extensions as low-risk — install, forget. This incident is a reminder that an extension runs with real privileges inside your editor, on your machine, with access to your code, your terminal and your credentials. A backdoored extension is not a minor compromise.
2. Credentials in traces are a slow-burning risk. The exposed traces were mostly from 2025. The credential stolen from them was used on 29 October 2026 — months later. A leaked credential doesn't expire just because the leak is old. If a key ever appeared in a trace, a log, or a prompt, it stays usable until you rotate it.

What to do now

If you use Cursor — especially if you use the Claude Code extension inside it — work through this list:

1. Check your Claude Code extension version. If you have version 2.1.312 or 2.1.313 installed from Cursor's marketplace, treat it as compromised: uninstall it, and reinstall a clean copy from the VS Code Marketplace or Open VSX. If you're unsure when you installed it, reinstalling from a trusted source costs you two minutes and removes the doubt.
2. Check for persistence mechanisms. On macOS, look at ~/Library/LaunchAgents for anything you don't recognise. On Linux, check your crontab (crontab -l) and system cron directories. On Windows, check Task Scheduler for unfamiliar tasks. The malicious builds tried to install a persistent SSH backdoor through exactly these mechanisms — if you find something you didn't put there, treat the machine as compromised and rebuild from a known-good state.
3. Audit SSH authorized_keys. Check ~/.ssh/authorized_keys on every machine you use with Cursor. An unfamiliar key there is the backdoor doing its job. Remove anything you don't recognise, and check the same file on any servers you SSH into from that machine.
4. Rotate any credential that ever appeared in a Cursor trace. If you used Cursor without Privacy Mode and ever pasted an API key, token or secret into a prompt or had one in code the agent processed, rotate it now — even if the trace is from 2025. The attacker sat on stolen credentials for months before using one. Old exposure is still exposure.
5. Enable Privacy Mode. This is the single setting that would have kept your code and prompts out of the exposed bucket entirely. In Cursor's settings, turn Privacy Mode on — it stops your code from being stored or used for training, and it is the difference between being in the affected group and not being in it.
6. Watch for Cursor's notification. Cursor says it notified affected users directly. If you received one, follow its instructions — it means your traces or credentials were in the exposed set.

The honest limits

• No hands-on verification. Everything above is Cursor's account of its own incident, as reported by BleepingComputer and The Hacker News. I have not examined the malicious builds, the marketplace cache, or Cursor's infrastructure.
• "Up to 5,000" is an upper bound. Cursor says up to 5,000 users may have received the trojanized versions. The number who actually installed and ran them could be lower — Cursor hasn't published that figure.
• No malicious activity since 1 November is Cursor's detection claim. It means Cursor has not detected further activity. It is not a guarantee that every compromised machine has been found — persistence mechanisms are designed to be quiet.
• The Fireworks breach itself is still partly opaque. How the Fireworks key was exposed in the first place is a question for Fireworks' own disclosure, not Cursor's.

My take

There are two stories here, and they're both worth sitting with. The first is that Cursor's response, on paper, is the right shape: notify, revoke, rotate, cut the provider off, rebuild the distribution path, redeploy. That's what a serious incident response looks like, and the speed — update published 13 November, days after the 10 November breach disclosure — is reasonable.

The second is the uncomfortable one: a single leaked vendor key cascaded into a trojanized extension served from a trusted cache to thousands of developers. The chain had at least three links — the Fireworks breach, the unredacted credentials sitting in historical traces, and a marketplace cache that could be written to with a stolen credential — and every link held. The fix for each link is different: better key hygiene with vendors, redaction that actually works in stored traces, and a marketplace cache that can't be poisoned by a single credential. Cursor has addressed the first and third by cutting Fireworks off and rebuilding the marketplace. The second — why API credentials were sitting unredacted in stored traces at all — is the question I'd most like a fuller answer to.

For now, the practical advice is short: check your extension version, check for persistence, rotate anything that ever touched a trace, and turn Privacy Mode on. Two minutes of checking beats finding out months later that a backdoor was sitting quietly in your LaunchAgents.

Were you running Claude Code 2.1.312 or 2.1.313 from Cursor's marketplace in late October? And has this changed how much you trust your editor's extension marketplace?

Sources: Cursor incident update, 13 November 2026 (primary source); BleepingComputer, 14 November 2026; The Hacker News — "Stolen Fireworks AI Key Led to Cursor Serving Backdoored Claude Code Extension to 5,000 Users" (https://thehackernews.com/2026/11/stolen-fireworks-ai-key-led-to-cursor.html), 15 November 2026. All incident facts, dates, version numbers and percentages are Cursor's as reported there. No hands-on testing was performed for this article. This breaking article is not the daily buyer-intent post, and it contains no affiliate links.

FAQ

What happened in the Cursor incident?
An access key Cursor had issued to Fireworks AI was exposed in the Fireworks breach. The attacker used it to copy a read-only bucket of historical coding-agent traces — mostly from 2025, from users without Privacy Mode enabled — some containing unredacted API credentials. On 29 October 2026 the attacker used a stolen credential to place trojanized copies of Anthropic's official Claude Code extension (versions 2.1.312 and 2.1.313) on the cache serving Cursor's extension marketplace, live for about 11 hours. Up to 5,000 users may have received them.

What did the backdoored Claude Code extension do?
The malicious builds tried to install a persistent SSH backdoor: LaunchAgents on macOS, cron entries on Linux, and scheduled tasks on Windows.

Which Claude Code versions were trojanized?
Versions 2.1.312 and 2.1.313, served from Cursor's extension marketplace cache. Anthropic's legitimate extension and the copies on Open VSX and the VS Code Marketplace were not affected.

Was my code affected if I use Cursor with Privacy Mode on?
No. Cursor says Privacy Mode users' code and prompts were not in the exposed traces. Customer code repositories, Cursor's production environment and official app updates were also unaffected.

What should I do if I installed Claude Code 2.1.312 or 2.1.313 from Cursor?
Uninstall it and reinstall a clean copy from the VS Code Marketplace or Open VSX. Check for persistence mechanisms (LaunchAgents on macOS, cron on Linux, Task Scheduler on Windows), audit ~/.ssh/authorized_keys, and rotate any credentials that ever appeared in a Cursor trace. Enable Privacy Mode.

How many users were affected?
Cursor says fewer than 0.05% of users had traces exposed and fewer than 0.01% had API credentials compromised. Up to 5,000 users may have received the trojanized extension versions during the roughly 11-hour window.

Is this the same as the Fireworks AI breach?
It started there, but it is a follow-up, not the same event. The Fireworks breach (disclosed 10 November 2026) exposed the key; the Cursor incident is what the attacker did with it — copying traces and then poisoning Cursor's extension marketplace cache on 29 October 2026.