Cursor traces its security breach to an access key exposed by Fireworks
Cursor has published the results of its two-week investigation into the security incident that put a tampered copy of the Claude Code extension in its marketplace on October 29, and the company now places the starting point outside its own systems. In an update dated November 13, Cursor says an attacker obtained an access key that Cursor had issued to Fireworks, a third-party inference provider, after Fireworks exposed it. With that key the attacker copied data from a read-only storage bucket that Cursor used to share data with the vendor, and from there moved into a limited set of Cursor's internal SaaS tools.
The figures Cursor gives are small in proportion to its user base, but they describe a real exposure. The bucket held coding agent traces, mostly from 2025, taken from sessions that were not running in Privacy Mode and that Cursor was permitted to use for model training. Some of those traces contained credentials that had never been redacted. Cursor says fewer than 0.01% of its customers had API credentials exposed this way, and that among users who were not using Privacy Mode, fewer than 0.05% had traces exposed. Every affected user was notified directly, and Cursor states that anyone who received no notice was not in the traces.
The company has also changed suppliers as a result. Cursor says it moved all inference away from Fireworks, deactivated the vendor's key and cut Fireworks' access to the datasets the two companies shared. The last attacker activity Cursor observed was on November 1, and the company says that attempt was blocked.
··········
HOW THE CURSOR BREACH STARTED AT FIREWORKS.
Cursor's account begins with a credential it controlled but did not hold. The key had been issued by Cursor to Fireworks so that the vendor could read from a shared bucket, and the bucket was read-only. Once Fireworks exposed the key, the attacker could use it to copy whatever that bucket contained, and Cursor's description of the contents explains why the incident spread further: historical agent traces from non-Privacy Mode sessions sometimes include API keys, tokens or passwords that a developer pasted or that a tool printed during a session.
Using credentials found in those traces, the attacker reached what Cursor calls select SaaS tools. Through them the attacker accessed archived, non-production source code repositories, some of which contained business contact information; limited customer support data and emails; product usage metrics and contact details; summaries of some agent conversations; and some credentials that users had sent to Cursor's support team. Cursor says its own monitoring detected the activity, after which it deactivated the vendor key, opened an incident response effort and rotated credentials as each new point of access was found.
Cursor also says it temporarily switched off internal and product services beyond what the evidence strictly required, which briefly disrupted some features, and restored them only once each service was judged safe. The company has engaged external forensics experts.
Fireworks has published its own bulletin, updated on November 9, which fills in the vendor side of the timeline. Fireworks says a third-party cloud provider hosting its research and development machines suffered a security incident on October 23, and that on October 24 an unauthorized party used that incident to reach Fireworks development machines and run an unauthorized workload. Fireworks says it detected the activity the same day and has seen no further evidence of successful unauthorized access to its customer platform since October 25. It links the attack to a financially motivated group that sells tokens from unauthorized access to language models through illicit routing gateways, a practice it calls LLMJacking. Fireworks says it has notified law enforcement and engaged Palo Alto Networks Unit 42 for forensic analysis.
··········
CURSOR AND FIREWORKS INCIDENT TIMELINE.
The two companies' statements fit together into a single sequence. The dates below come from Cursor's November 13 update, its October 29 security notice and the Fireworks bulletin.
........
Date (2026) | Event | Source |
October 23 | Incident at a cloud provider hosting Fireworks R&D machines | Fireworks |
October 24 | Unauthorized party reaches Fireworks development machines; detected same day | Fireworks |
October 29, about 2:27am to 1:35pm PT | Tampered Claude Code extension 2.1.312 and 2.1.313 served from Cursor's marketplace cache | Cursor |
October 30 | Cursor publishes indicators of compromise, check scripts and remediation steps; notifies users and admins | Cursor |
November 1 | Last observed attacker activity, blocked | Cursor |
November 9 | Fireworks updates its security bulletin | Fireworks |
November 13 | Cursor publishes investigation results and moves all inference off Fireworks | Cursor |
........
··········
THE TAMPERED CLAUDE CODE EXTENSION IN THE CURSOR MARKETPLACE.
The part of the incident that most Cursor users saw directly was the extension. Cursor now confirms that the attacker used a stolen credential to place malicious copies of the Anthropic.claude-code extension in the cache that serves Cursor's VS Code extension marketplace. Cursor states that Anthropic did not publish those builds and that the incident did not involve a vulnerability in Anthropic's product. The Open VSX registry never carried the malware.
According to Cursor, the tampered builds were available for about 11 hours, and at most 5,000 users who requested those specific cached versions on October 29 could have received them. Cursor took the marketplace offline, validated the remaining extensions as authentic, rebuilt the marketplace and worked with the hosting provider to take down the attacker's server. We covered the original notice in our report on the malicious Claude Code extension in the Cursor marketplace.
The October 29 notice describes what the tampered build tried to do on macOS and Windows machines. It collected host details such as hostname, username, operating system, home directory, environment variable names, Git email and public IP address. It tried to add an attacker-controlled SSH key to the user's authorized keys, enable the local SSH service and open a reverse SSH tunnel, and it installed persistence through a LaunchAgent on macOS or a scheduled task named SysMon on Windows. Cursor says the tunnel would generally fail unless Cursor was running with administrator privileges, because of errors in the attacker's code. The key, the persistence and the reporting of host details could still succeed, which is why Cursor asks everyone who installed the affected versions to follow the full remediation.
··········
WHAT CURSOR SAYS WAS AND WAS NOT EXPOSED.
Cursor's update draws a clear boundary around the incident, and that boundary is the most useful part of the disclosure for companies deciding how to respond. The table summarizes the company's statements.
........
Area | Status according to Cursor |
Historical agent traces, non-Privacy Mode sessions | Exposed for fewer than 0.05% of non-Privacy Mode users |
API credentials inside those traces | Exposed for fewer than 0.01% of customers |
Archived non-production repositories | Accessed |
Support data, emails, credentials sent to support | Limited data accessed |
Product usage metrics, conversation summaries | Some accessed |
Privacy Mode prompts and code | Not affected |
Live traffic and active inference requests | Not exposed |
Production systems and infrastructure | Not affected |
Cursor app and official updates, release signing keys | Not affected |
Customer code repositories | Not affected |
Other marketplace extensions and Cursor Marketplace plugins | Not affected |
Cloud Agents, Grok Bot and other SpaceX SI products | Not affected |
........
Cursor says the Cursor app and its updates ship from a separate code hosting system that the attacker never accessed, and that no release signing keys were exposed. For an organization running Cursor on developer machines, that statement separates two risks: a compromised editor update, which Cursor rules out, and a compromised third-party extension served during a fixed window, which Cursor confirms.
The trace exposure is tied to a setting. Cursor's statements limit it to sessions that were outside Privacy Mode and whose data Cursor could use for training, and the company says the exposed data came from historical storage kept for offline analysis, with nothing sent to Cursor today affected. Teams that enforce Privacy Mode were outside this part of the incident, according to the company.
··········
[[ADPLUS_300x250_1]]
WHAT CURSOR USERS AND ADMINS SHOULD DO NOW.
Cursor's guidance depends on which group a user or organization falls into, and the company has already contacted everyone it identified. The steps below follow the November 13 update and the October 29 notice.
........
Situation | Action Cursor recommends |
Installed or updated Anthropic.claude-code 2.1.312 or 2.1.313 from the Cursor marketplace on October 29 | Follow the October 29 notice in full; uninstalling the extension alone may not be enough |
Notified that credentials were exposed | Rotate every key on the list sent to you or your admin |
Team admin who received a key list | Rotate the listed keys; Cursor has asked third-party issuers to revoke them |
Contacted about support or business data | Follow the details in Cursor's direct message |
Received no notice | Cursor says your data was not in the affected traces |
Any remaining question | Write to security@cursor.com |
........
For machines that may have run the tampered extension, the October 29 notice gives a quick test based on the comment string the attacker's SSH key carries. On macOS the check is the following command, which finishes with exit status 0 when the key is present:
grep -qs svc-telemetry ~/.ssh/authorized_keysOn Windows, Cursor says to search both $HOME\.ssh\authorized_keys and C:\ProgramData\ssh\administrators_authorized_keys for the svc-telemetry string with Select-String in PowerShell. If the key is found, Cursor treats the machine as affected and lists five steps: isolate the host, remove the SSH key, the persistence files and any running tunnel processes, assess whether to rebuild the machine, rotate credentials and sessions reachable from it using a trusted system, and run Cursor's remediation script, which exits with a non-zero status if anything remains. Cursor adds that the limited collection of environment variable names does not rule out later access to credentials over the backdoor, so rotation is part of the recommended response even when nothing else looks wrong.
··········
HOW THE FIREWORKS BREACH REACHED CURSOR AND NOTION.
Cursor follows Notion in tracing customer data exposure to Fireworks this month. Notion's security advisory, updated on November 10, said AI chat transcripts from under 1% of workspaces were exposed through the same vendor, as we reported in our coverage of the Notion AI exposure in the Fireworks breach. Cursor's case adds a second step to the chain: a Cursor-issued key exposed by the vendor opened Cursor's own shared bucket, and credentials inside the traces stored there then opened several of Cursor's internal tools.
Fireworks' bulletin lists what was accessed on its side: secrets stored by Fireworks, such as those used in evaluation jobs; resource metadata; billing information including addresses, invoice and payment history, account balance and credit usage; and, for a limited set of accounts, secrets, datasets and incomplete model weights. Fireworks says it does not store payment card numbers and that it detected no impact on its Inference, Training SDK or Nexus products, which it describes as zero data retention by default. It has disabled self-serve dataset uploads and downloads for Batch Inference and dataset-based training while the investigation continues, and it does not give a number of affected customers.
For buyers of AI coding tools, the Cursor case puts a specific question on vendor reviews: which inference and data partners receive keys or datasets from the tool provider, what those keys can reach, and whether historical telemetry is retained in a form that can carry secrets. Cursor's own response points to the controls it found lacking, since the company says it has added secret scanning across its code repositories, extended scanning to other internal data sources and expanded network access restrictions with service providers where possible.
··········
CURSOR SECURITY INCIDENT: CONFIRMED FACTS AND OPEN QUESTIONS.
Cursor has now stated the entry point, the reach and the scale of the incident in its own words. The attacker began with a Cursor-issued key exposed by Fireworks, copied historical non-Privacy Mode traces from a read-only bucket, used credentials found in those traces to access archived repositories, support data and usage metrics, and used a stolen credential to plant a tampered Claude Code extension that could have reached up to 5,000 users over about 11 hours. Cursor says production systems, live traffic, Privacy Mode data, customer repositories and the Cursor app itself were untouched, and it has moved all inference off Fireworks.
Several points remain undisclosed. Cursor gives percentages instead of absolute numbers of affected customers and users, and it does not say how many machines actually installed the tampered builds as opposed to the maximum that could have received them. Fireworks has not published how the access key was exposed in technical detail, and its investigation is still marked as active. Cursor has not said whether Fireworks will return as an inference provider or which providers now carry the traffic. The company says it will update its post if anything important changes, and for administrators the remaining work is concrete: confirm that every key on Cursor's list has been rotated and that no developer machine still carries the svc-telemetry key.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
