Picture a developer settling in for an ordinary Thursday morning. Coffee on the desk, code editor open, and a familiar extension update waiting in the corner of the screen.
They click update. Nothing looks wrong. The extension loads, the code flows, and the day goes on as normal.
What they cannot see is that the update did not come from the company that built it. For about eleven hours on October 29, a tampered copy of a popular coding extension sat in the cache serving Cursor’s marketplace, and up to 5,000 users may have installed it.
Now, in a detailed incident report published on November 13, Cursor has explained how it happened. The trail does not start inside Cursor at all. It starts at Fireworks AI, one of its inference vendors, and with a single access key that should never have fallen into the wrong hands.
How the Cursor Security Breach Began at Fireworks AI
Cursor builds one of the most widely used AI coding tools in the world. Like many AI companies, it does not run every model on its own machines — some inference work runs through outside vendors, and Fireworks AI was one of them.
To make that work, Cursor had issued Fireworks an access key. It opened a read-only storage bucket the two companies used to share data. According to Cursor, that key was exposed at Fireworks, and an attacker picked it up.
With the key in hand, the attacker copied what was inside the bucket: historical coding-agent traces, mostly from 2025, from sessions not using Cursor’s Privacy Mode. Cursor says this was data it was permitted to use for model training.
For most users, that was the end of the damage. Cursor puts trace exposure at fewer than 0.05 percent of users. But a small number of those traces contained something far more dangerous: credentials that had never been redacted.
What the Attacker Found Inside the Traces
Agent traces record what a coding assistant did: prompts, tool calls, fragments of the work itself. In a handful of cases, they also contained secrets that should have been scrubbed out before the traces were ever stored.
Cursor says fewer than 0.01 percent of customers had API credentials exposed this way. It was a tiny fraction, but it was enough. The attacker used those credentials as a doorway into software tools Cursor itself uses every day.
From there, the picture widens. The attacker reached archived, non-production source code, some containing business contact information, plus limited support data, email conversations, usage metrics and summaries of coding-agent conversations.
Most sensitive of all, they found credentials users had sent to Cursor’s support team. Those were never meant to be in any trace or archive, yet there they were, waiting to be picked up.
The Fake Claude Code Extension That Reached 5,000 Users
The intrusion might have stayed a quiet data theft. Instead, on October 29, it turned into something users could feel. Using a stolen credential, the attacker placed modified copies of Anthropic’s Claude Code extension into the cache that serves Cursor’s VS Code extension marketplace.
The tampered builds were versions 2.1.312 and 2.1.313 of Anthropic.claude-code, available for roughly eleven hours, from 2:27 a.m. to 1:35 p.m. Pacific Time. Cursor estimates at most 5,000 users who requested those cached versions potentially received a malicious build.
Cursor drew a line around what happened next. Anthropic did not publish the modified copies, and the malware never appeared on Open VSX, the upstream registry. Cursor’s production systems, official updates, release-signing keys and customer code repositories were not affected.
Still, the episode showed how quickly a stolen key can become a supply-chain attack. One exposed credential, taken from a forgotten trace, ended up inside the update pipeline of thousands of developers.
What Was Spared — and Who Was Told
Not everything the attacker touched was damaged. Current customer data, live traffic and active inference requests were not affected. Privacy Mode prompts and code were untouched, and so was the code shipped to clients and cloud services.
That code lives in a separate hosting system the attacker never reached, and no release-signing keys were exposed. The company also validated every other extension in its marketplace and rebuilt the store from scratch.
Cursor published indicators of compromise and remediation material on October 30, a day after the tampered extension appeared. It began notifying affected users and team administrators through in-app messages and email.
Administrators received lists of the exposed keys, so they could rotate them. Cursor also asked the third-party services that issued them to revoke them. Customers whose support or business data may have been involved were contacted directly.
Cursor Cuts Ties With Fireworks
Cursor’s own monitoring spotted the unauthorised activity, and the response was deliberately heavy-handed. It temporarily disabled more services than the evidence required, as a precaution, restoring each one only after review.
Then came the bigger decision. Cursor moved all inference traffic off Fireworks, deactivated the vendor key, and cut off Fireworks’ access to every shared dataset. The partnership, in practical terms, is over.
Every exposed credential was rotated, and then Cursor went further, rotating all credentials across its internal systems, even where there was no evidence of exposure. Network restrictions were expanded, and secret scanning was added to code repositories and other internal data sources.
Production was redeployed, the marketplace rebuilt, and external forensic experts brought in. Cursor believes the incident is contained: the last attacker activity it observed, on November 1, was blocked. Monitoring continues.
The One Question Cursor Cannot Answer Yet
One caveat hangs over the whole account. The claim that the key was exposed by Fireworks is Cursor’s version of events. Fireworks’ own security bulletin, last updated on November 9, does not mention Cursor at all.
Fireworks has disclosed two intrusions of its own. One was detected on October 6. The second came on October 23 and 24, through a third-party cloud provider hosting its research-and-development machines, where an unauthorised party ran a workload that caused more customer-data impact.
Fireworks says it detected that activity the same day and has seen no further successful unauthorised access on its customer platform since October 25. But it is not public which intrusion exposed Cursor’s key, and Fireworks’ findings remain under investigation.
That gap matters. Until Fireworks confirms the chain, the most serious link in it rests on one company’s word. Cursor’s report is detailed and specific, but the vendor side of the story is still unfinished.
Why This Breach Matters Beyond Cursor
The Cursor incident did not happen in isolation. It is part of a wave of October breaches that trace back to the same vendor. The Fireworks AI breach itself exposed customer datasets and model weights, and just this week Uber confirmed a data breach that came through the same vendor.
Notion has also disclosed that some of its AI chat transcripts were exposed after a breach at Fireworks. Add the Grok Build leak, which left tens of thousands of AI-built apps open to anyone, and a pattern starts to form.
The pattern is this: AI companies now share data, keys and infrastructure with a small circle of vendors, and a single weak link can reach into all of them.
A key issued for one purpose, a trace stored for training, a cache that serves an extension marketplace — each one is a door, and the doors are connected.
Cursor, Apify and Epoch AI all published incident reports on the same day, November 13. The tools that write our code, scrape our web and benchmark our models are themselves becoming targets — and their records are becoming attack surfaces.
For users, the practical lessons are familiar but worth repeating. Turn on Privacy Mode where it exists, and treat anything you paste into a support ticket as something that could one day leak. Keep your extensions and credentials rotated, because the update you install tomorrow may not have come from where you think.
For the industry, the lesson is sharper. Cursor did much of what a good incident response should do: it disclosed, it notified, it rotated, and it cut the vendor loose.
But the breach began with a key Cursor had handed to someone else, and a trace it had kept for training. The next key may open a wider door. According to Unite.AI, the vendor-side findings are still open to revision — and that is the part the industry should be watching.
