Cursor Says Fireworks AI Leak Exposed Key Behind Extension Attack

By James Calloway

Cursor traced a months-long intrusion chain to a single access key that Fireworks AI exposed, according to an incident update published November 13, 2026. The attacker used that Cursor-issued key to copy historical coding-agent traces from a shared storage bucket, harvest credentials left inside them, and ultimately push malicious Claude Code extension builds to Cursor's VS Code marketplace. Fewer than 0.01% of customers had API credentials exposed, Cursor said.

The disclosure answers a question Cursor had left open since October 30, 2026, when it first reported the malicious extension builds without a root cause. The answer places the origin of the breach outside Cursor's own infrastructure — with an inference vendor that held a key to Cursor's data. That framing matters commercially: AI coding assistants live on customer trust in how their prompts, code, and traces are handled, and this incident shows a vendor relationship quietly widening the attack surface.

What did the attacker actually reach?

The exposed key opened a read-only bucket Cursor used to share data with Fireworks for model training. Its contents included limited coding-agent traces, mostly from 2025, drawn from sessions where users had not enabled Privacy Mode (the setting that excludes prompts and code from training use). Cursor was contractually permitted to use that material for model training. A small number of traces contained unredacted credentials, and those became the attacker's route into select software-as-a-service tools used by Cursor.

Through those SaaS tools, the attacker reached select archived, non-production source repositories, some containing business contact information. Other accessed material included:

• limited support data and email conversations;
• product-usage metrics and contact details;
• summaries of some coding-agent conversations;
• credentials users had sent to Cursor's support team.

Among users not using Privacy Mode, exposed traces covered fewer than 0.05%, and Cursor said it identified and notified each affected user directly. Those traces were confined to storage used for historical offline analysis. Current customer data, live traffic, active inference requests, and Privacy Mode prompts and code were not affected.

The pattern here is a familiar one: the breach did not defeat a security control so much as exploited data that should never have contained plaintext secrets in the first place. Credentials embedded in historical traces are the quiet failure point of every incident of this shape.

What was not touched?

Cursor drew a firm line around its production systems. The company reported no impact to the infrastructure running its service or to customer code repositories. Official app updates and code shipped to clients and cloud services were unaffected, because release code sits in a separate hosting system the attacker never accessed. No release-signing keys were exposed — the detail that would have turned a contained incident into a supply-chain catastrophe.

Cursor also validated all other extensions in its VS Code marketplace and reviewed and rebuilt the store. That is a reassuring claim, though "reviewed and rebuilt" is the extent of the detail offered; the company has not described the review's methodology.

How did the key become malicious extensions?

The update links the intrusion to Cursor's earlier malicious Claude Code extension disclosure. On October 29, 2026, the attacker used a credential stolen from the exposed internal data to place unauthorized builds directly on the cache serving Cursor's VS Code extension marketplace. Anthropic did not publish them, its product was not vulnerable, and Open VSX — the upstream marketplace source — never carried the malware. Cursor estimates at most 5,000 users who requested specific cached versions potentially received a malicious build during roughly 11 hours of availability.

The 11-hour window and the cache-only distribution limit the blast radius on paper. What the estimate does not specify is how many of those 5,000 potential recipients actually executed the malicious build.

Cursor published indicators of compromise and remediation material on October 30, 2026, and began notifying affected users and team administrators through in-app messages and email. Administrators received lists of specific keys to rotate where credentials were exposed, and Cursor asked the issuing third-party services to revoke those credentials directly. Customers whose support or business data may have been involved were notified separately.

Cursor's own monitoring systems flagged the unauthorized activity, not the vendor's. The company temporarily disabled more internal and product services than the evidence strictly required, disrupting certain features, and restored each after review. Cursor believes the incident is contained: the last attacker activity it observed occurred on November 1, 2026, and was blocked. Monitoring for anomalous activity continues.

What did Cursor do to close the gap?

The remediation list is broad, and notably extends beyond what the evidence demanded:

• moved all inference traffic off Fireworks;
• deactivated the vendor key and cut off Fireworks' access to all shared datasets;
• rotated every exposed Cursor credential, then rotated all credentials across internal systems as a precaution even without evidence of exposure;
• expanded network restrictions across service providers;
• added secret scanning to code repositories and internal data sources;
• redeployed production infrastructure and engaged external forensics experts.

Rotating every credential in use is the expensive, correct response to an intrusion whose full scope is uncertain. It also signals Cursor could not fully rule out additional exposure — a caveat worth holding against the word "contained."

What does Fireworks AI's own report say?

Fireworks AI's security bulletin tells the vendor side of the story, and it begins earlier than Cursor's account. A third-party cloud provider hosting Fireworks' research-and-development machines experienced an incident on October 23, 2026. On October 24, 2026, an unauthorized party reached Fireworks development machines and ran an unauthorized workload that led to additional customer-data impact. Fireworks detected the activity that same day. It has not detected further successful unauthorized access on the customer platform since October 25, 2026. Those findings remain subject to an ongoing investigation — meaning the timeline above could still change.

Fireworks revoked and replaced credentials and service accounts, removed unnecessary elevated privileges, restricted network pathways, tightened storage and analytics access controls, and enhanced logging and monitoring with assistance from Palo Alto Networks Unit 42. It also disabled self-serve dataset uploads and downloads used by Batch Inference and dataset-based training during the investigation. The Training SDK remains available with zero data retention — no training data stored at rest — while Lab-based training operates in an isolated environment.

Why the chain matters more than any single failure

The new account places the marketplace compromise at the end of a chain: a vendor key exposed at Fireworks, credentials left in historical traces, access to Cursor's SaaS tools, then poisoned marketplace builds. No single link was catastrophic on its own. The chain was.

That makes vendor-access revocation and broad credential rotation central to Cursor's containment assessment, and it makes Fireworks' still-open investigation the loose end. For AI vendors and their customers, the operational lesson is concrete: every dataset shared with an inference provider is only as protected as that provider's development machines — and the traces inside it must be treated as secrets until proven otherwise.