Cursor says a key exposed by Fireworks led to the malicious Claude Code extension; three figures, three groups
Cursor's update of 13 November 2026 says a key exposed by Fireworks began the chain that put malicious Claude Code copies on its marketplace cache on 29 October. It prints three figures that count three different groups, and no absolute count for any of them.
By Parminder Kumar Sharma · LinkedIn · · 19 min read
Three figures, three groups, and not one absolute count
Cursor's update of 13 November 2026 prints three figures about who was affected, and each counts a different group. Coding agent traces were exposed for "fewer than 0.05% of users". Cursor says "less than 0.01% of customers had API credentials exposed". And "At most 5,000 users who requested specific cached versions" of the extension on 29 October "potentially received the malicious build". A share of users, a share of customers and a ceiling on requesters cannot be added, compared or turned into one number, and the page prints no user count, no customer count and no method for any of the three. Converted, the first two are fewer than 1 in 2,000 and fewer than 1 in 10,000 (derived: 1 divided by 0.0005 and by 0.0001), of bases the page does not give.
What that does not establish. It does not say how many people or organisations were hit, how many of the up to 5,000 ran the payload, or whether the three groups overlap. The dates give the same kind of gap. Cursor's 29 October notice puts the extension window at about 2:27am to 1:35pm Pacific time, which is 11 hours 8 minutes (derived: 13:35 minus 02:27), against "approximately 11 hours" in the update. The update was posted 15 days after the extension appeared (derived: 29 October to 13 November), and its last dated sign of the attacker, 1 November, is 3 days after the extension and 12 days before the post (derived). It dates neither the exposure of the key at Fireworks, nor the copy of the bucket, nor the first use of the stolen credentials.
Whose account this is matters. Cursor sells the editor and runs the marketplace, so the update is both the primary record and the account of a party with a stake in how the incident reads, and it blames a partner by implication: the key "was exposed by Fireworks". Fireworks' bulletin index, re-read at 20:24 UTC on 14 November 2026, lists nothing newer than 9 November, and neither Fireworks bulletin names Cursor. This is Cursor's account of a partner's failure, and no saved page carries Fireworks' reply. Brief 524 on this site covered the 29 October notice and an outside advisory; this briefing is about what the 13 November update adds.
What happened, in the order Cursor gives it
Cursor's update says the incident "started at Fireworks". An attacker obtained an access key Cursor had issued to Fireworks, the key "was exposed by Fireworks", and the attacker used it to copy data from a read-only storage bucket that Cursor used to share data with Fireworks. The bucket held limited coding agent traces, mostly from 2025, from sessions not in Privacy Mode, which Cursor says it was permitted to use for model training. A small number of the traces held credentials that had not been redacted.
From those credentials the attacker, Cursor says, reached select SaaS tools and took select archived non-production source repositories (some holding business contact information), limited support data and email conversations, product usage metrics and contact details, summaries of some coding agent conversations, and some credentials users had sent to Cursor's support team. On 29 October "using a stolen credential from the exposed data from our internal system", the attacker placed malicious copies of Anthropic's Claude Code extension directly on the cache that serves the Cursor marketplace. Cursor says Anthropic did not publish the copy, that it was not a vulnerability in Anthropic's product, and that "The marketplace source, Open VSX, never had the malware". The extension was up for approximately 11 hours.
The response is described without dates. Cursor says its monitoring found the activity, it deactivated the vendor's key, opened an incident response workstream and began rotating credentials, and it temporarily disabled internal and product services "well beyond what the evidence required". It says it moved all inference traffic off Fireworks, rotated every exposed credential and, as a precaution, all credentials in use across internal systems, rebuilt the marketplace, redeployed production infrastructure and engaged external forensics experts. It says "We believe the incident is contained" and that the last attacker activity it saw was on 1 November and was blocked.
The order inside that account is not a dated sequence. The update says Cursor deactivated the key after becoming aware of the activity, and separately that the attacker used a stolen credential on 29 October. It does not say whether the key was deactivated before or after the cache was written, and it does not say which credential was used or where in the traces it was found. The 29 October notice says only that Cursor "rotated our keys, rebuilt the marketplace, and brought it back online", and the update says the last activity it saw was three days later. This site does not infer an order.
The update also lists what it says was not affected: prompts and code for users in Privacy Mode, live traffic, production systems, the Cursor app and its official updates (shipped from a separate code hosting system the attacker never accessed, with no release signing keys exposed), customer code repositories, every other extension in the marketplace and any plugins downloaded from it. It names Cloud Agents for customer teams, Grok Bot and "all other SpaceX SI products" among the unaffected; the 29 October notice prints that name as SpaceXSI, and neither page explains how the group relates to Cursor.
Whose numbers: three figures, three groups
The first figure sits in a sentence that begins "For users not using Privacy Mode" and ends "fewer than 0.05% of users". The base may be all users or only users outside Privacy Mode; the sentence does not say. Cursor says it identified those users and notified each directly, and that "If you did not receive a notification, your data was not in these traces". That is a test a reader can apply to themselves and cannot check. The second figure is a share of customers, a different unit, and the page does not say what a customer is. The third is a ceiling on users who requested particular cached versions on one day, who "potentially received" the build: not installs, not everyone with the extension, and not the number who ran it.
Cursor's three figures: what each counts and what is not printed. Source: Cursor's update of 13 November 2026, as read on 14 November.
| Figure as printed | What it counts | Not printed |
|---|---|---|
| Fewer than 0.05% | Users whose coding agent traces were exposed | Whether the base is all users or users outside Privacy Mode; any user count; how it was measured |
| Less than 0.01% | Customers whose API credentials were exposed | Any customer count; what a customer is; how the credentials were found |
| At most 5,000 | Users who requested specific cached versions on 29 October and potentially received the build | How the ceiling was reached; how many ran the payload; how it relates to the other two groups |
A fourth number has moved. The copy of the 29 October notice that brief 524 saved on the morning of 30 October printed "At most 5,000 users were affected, and we will reach out directly". The notice as saved on 14 November, after an edit stamped 30 October, 11:30 am PT, prints no user figure at all. The update now carries the 5,000, with a different unit: not users affected, but users who potentially received the build. The method is no more visible than before.
Fireworks' pages and Cursor's pages: two tracks and no link
Fireworks published two bulletins. The first says that on 6 October it identified unauthorized use of internal credentials, and that an unauthorized third party "accessed environment variables used in evaluation jobs in a limited number of customer accounts". The update, last updated 9 November, says a third-party cloud provider hosting Fireworks research machines had an incident on 23 October, that the unauthorized third party reached Fireworks development machines on 24 October, and that the evidence indicates links to a financially motivated group engaged in "LLMJacking". Brief 650 covers those bulletins.
Neither bulletin names Cursor, any other customer or any key held by a partner, and the index re-read on 14 November lists nothing since 9 November. Cursor's update names Fireworks and gives no Fireworks incident date. The saved pages do not say that the key Cursor issued was one of the secrets captured on 6 October, or anything reached on 23 or 24 October. This site does not link them, and the dates of the key exposure, the bucket copy and the first use of the stolen credentials stay in the not stated column.
BleepingComputer, which this site read as a relay, says the Fireworks incidents "also affected other customers, including Notion". The saved Fireworks pages name no customer, so that is BleepingComputer's statement and not Fireworks'. The relay also ties the case to what Wiz has called "Black October", a wave of attacks on AI developer platforms, and lists other companies and a fraud figure for one of them. None of that is on Cursor's page, and Wiz's report was not read by this site.
Friendly labels: read-only, non-production, limited, select
Several words in the update do the work of reassurance without carrying a number. A label describes a permission or a category; it does not describe what is inside. The table sets each beside what the same page says.
Labels in Cursor's update of 13 November 2026 and what the same page says about the contents. Quoted words are the page's.
| Label on the page | What the page says is inside | What the page does not say |
|---|---|---|
| "read-only" | Coding agent traces, a small number holding unredacted credentials, from which the attacker reached SaaS tools | How many traces held credentials; what kind; whether the bucket was scanned before sharing |
| "non-production" | Archived source code repositories, some holding business contact information | How many repositories; whether any held credentials; what the contact information was |
| "limited" | Coding agent traces; customer support data and email conversations | What limited means as a count, a date range or a share of the bucket |
| "select" | SaaS tools used by Cursor | Which tools; which of them held the credential that reached the marketplace cache |
| "Privacy Mode" | Sessions outside it produced traces that Cursor was permitted to use for model training | Whether any trace was used for training; how long the 2025 traces were kept; how Privacy Mode is enforced |
The page says the traces were data Cursor "we were permitted to use for model training". It does not say any were used for training. A read-only bucket is read-only to whoever holds the key to it; it still hands over everything inside, and by Cursor's own account some of what was inside was a credential. That is the chain's turning point, and it is where a control is described by a label.
Where the pages differ
These differences are reported and left as they are. The saved pages do not settle them.
Differences inside and between the saved records. Each entry says what each page prints; this site resolves none.
| Point | What the pages print | How this briefing handles it |
|---|---|---|
| Date of the notice | The update says "On October 29, we shared that we were investigating" and later "On October 30, we published a security notice on our blog and on X". The saved notice is dated Oct 29, says today about the 2:27am to 1:35pm PT window, and carries an edit line stamped Oct 30, 11:30 am PT. The copy brief 524 saved at 11:38 GMT on 30 October already had an indicators section. | Both dates reported. Whether 30 October means the edit, the X post or a first publication is not stated. |
| What the 29 October notice says about the cause | It says the versions "was made available in the Cursor VS Code Extension Marketplace" and that "We audited access and confirmed no other extensions were tampered with". It never mentions Fireworks, traces, a stolen credential or data theft. The update says this was the same incident. | Both quoted. The notice is not called wrong; it is called silent on the rest. |
| Whether any host was taken over | The notice says that turning on the local SSH service needs admin rights, which on most macOS and Windows hosts the extension lacks, so the step fails. The update says nothing more about any host. | Not established. The update does not say whether any of the up to 5,000 hosts ran the payload to completion. |
| The 5,000 | Earlier notice copy: users affected. Current notice: no figure. Update: users who requested specific cached versions on 29 October and potentially received the build. | Unit and wording differ; the number does not. The update adds no method. |
| Where the key came from | Cursor: an access key issued to Fireworks was exposed by Fireworks. Fireworks' bulletins describe secrets in evaluation jobs, a cloud provider incident on 23 October and a development machine incident on 24 October, and never name Cursor. | Not linked. Dates and route are in the not stated column. |
| How BleepingComputer states it | "Cursor estimates" that up to 5,000 users "may have received" the build; the attackers "had already obtained a credential that allowed them to distribute extensions" through the marketplace. | Cursor's page says at most 5,000 and does not say estimate; it says the copies were placed directly on the cache, and it does not describe a distribution permission. Cursor's words govern here. |
One more point about the versions. The notice calls both 2.1.312 and 2.1.313 malicious. The Open VSX registry listing brief 524 saved on 30 October lists a genuine 2.1.312 stamped 27 October 2026, 20:26 UTC, and no 2.1.313 (the lookup for it returned not found). Cursor says Open VSX never had the malware and that the copies sat on its own cache. How a cached file called 2.1.312 related to that registry entry is not stated, and this site draws no conclusion.
What Cursor states, and what it does not
Cursor's update of 13 November 2026: stated and not stated, as read on 14 November 2026.
| Topic | Stated | Not stated |
|---|---|---|
| The attacker | An attacker obtained a key, accessed data, placed the extension copies | Who; any group name; any motive. This site names no persona |
| The key | Issued to Fireworks; exposed by Fireworks; deactivated by Cursor | How it was exposed; whether it was in either Fireworks bulletin; the date of exposure; the date of deactivation |
| The bucket | Read-only; limited traces, mostly 2025; sessions not in Privacy Mode | The date it was copied; the number of traces; how many held credentials |
| The SaaS tools | Select tools reached; five categories of data listed (counted by this site) | Which tools; how many repositories; what business contact information they held; dates |
| The cache credential | A stolen credential from the exposed data placed the copies on 29 October | What the credential was; why one from that data could write to the marketplace cache; when it was first used |
| The build served | At most 5,000 users who requested specific cached versions on 29 October potentially received it; about 11 hours | How the figure was derived; how many ran the payload; whether any host was taken over |
| Training use | Traces were data Cursor was permitted to use for model training | Whether any customer data in traces was used for training |
| Other parties | Anthropic did not publish the copy and its product was not vulnerable; Open VSX never had the malware | Any statement from Fireworks, Anthropic or Open VSX about Cursor's account |
| The investigation | Two weeks of investigation; external forensics experts engaged; contained; last attacker activity seen 1 November, blocked | Who the experts are; whether they agree; any finding of theirs |
What the notice's own edit changed
The update prints no indicators of compromise: no hash, address, file name or command. The notice does, and it changed after it was first read. Brief 524 saved the notice at 11:38 GMT on 30 October; this site saved it again on 14 November, with an edit line stamped 30 October, 11:30 am PT: "We updated the IOCs and clarified affected versions". Comparing the two copies line by line, the changes are below. The network indicators, the planted key and its fingerprints and the process and command line indicators are the same in both, so they are not repeated here; they are in brief 524.
Changes between the notice as saved on the morning of 30 October (brief 524's copy) and as saved on 14 November 2026. Both are Cursor's page.
| Item | Earlier copy | Copy of 14 November |
|---|---|---|
| Versions named | 2.1.313 only | 2.1.312 and 2.1.313, for Windows and MacOS |
| User count | At most 5,000 users affected | No count |
| 2.1.313 darwin-arm64 package hash | One value | A different value (the earlier value is in brief 524) |
| 2.1.313 win32-x64 package hash | One value | The same value |
| 2.1.312 package hashes | Absent | Present for darwin-arm64 and win32-x64 |
| Payload file hashes | Absent from the notice | A SHA-256 and an MD5 for extension.js |
| Linux | No Linux entry under files and persistence | A Linux entry and a cron persistence line |
| Effect on hosts | The extension "still adds" the key, installs persistence and sends host details | Past tense: the extension "added the attacker's SSH key, installed persistence, and sent host details" |
| Other products | Not mentioned | Other extensions, Grok Bot, Grok and other SpaceXSI products not affected |
Brief 524 printed the hashes as the notice then read, and its darwin-arm64 value for 2.1.313 is not the value the notice prints now. A defender hunting for packages should use the notice's current values, below, and compare against both while the difference is unexplained. The block is copied from the notice and attributed in its caption. A hash identifies a packaged file; it does not show that a machine ran it. The notice's own check for the planted key is in brief 524 and is not repeated.
Package version 2.1.312
Modified VSIX SHA-256 (darwin-arm64): fcbb327e38e61c4fec795e0d0591f52cd1014b813d20a5912104953c3a17c364 (MD5 e0d64d53e802a0217ba6f0e656ed2f20)
Modified VSIX SHA-256 (win32-x64): 3de1722901165769893bef57c72594e9a54459faa23f3091b136b79966edd081 (MD5 bd3b71ddf3d0cc3af76249afd2c0eda1)
Package version 2.1.313
Modified VSIX SHA-256 (darwin-arm64): 80402fdcad8799285fd93044976973ca000da7995fb93363f819bb8e4f84ee6c (MD5 34e491161e056c9b899a79b602ac73b9)
Modified VSIX SHA-256 (win32-x64): 6786ec90cbd45949695bd7805c9fbb26cfc91bc5fc897de0183d9bcb9cb21731 (MD5 7838a3be2ca0ff08c1bdb160ef516d39)
SHA-256: ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15
MD5: f49bcd657ef1e626e85ce858958c1769
The Linux entry is new in the edit. It tells a defender where a Linux host would hold the persistence files. It is Cursor's text, copied, and says nothing about whether any Linux host received the extension: the notice names Windows and MacOS as the platforms.
Linux / macOS: unauthorized key in ~/.ssh/authorized_keys; ~/.config/.smt, ~/.config/.smtk
Linux: /tmp/.stk_<10 hex>; cron @reboot /bin/sh "<HOME>/.config/.smt"
Cursor's remediation scripts, linked from the notice, were not downloaded or opened for this briefing.
What to do, in order
The first three steps are the vendor's. The rest are this site's suggestions and are labelled.
Take this with you
In order of urgency
- Cursor's step: if you installed or updated Anthropic.claude-code 2.1.312 or 2.1.313 from the Cursor VS Code Extension Marketplace on macOS or Windows on 29 October 2026, between about 2:27am and 1:35pm Pacific time, follow Cursor's security notice. Cursor says uninstalling the extension alone may not be enough.
- Cursor's step: rotate credentials and sessions reachable from an affected machine, from a trusted system, and isolate hosts that show the key or persistence the notice lists.
- Cursor's statement: Cursor says it contacted each affected customer directly and that no notification means your data was not in the traces. Questions go to the security address on Cursor's page.
- This site's suggestion: if you used Cursor outside Privacy Mode in 2025, treat any secret you ever typed or pasted into an agent session, or sent to Cursor support, as worth rotating even without a notice, because the page gives no count and no test other than the notice.
- This site's suggestion: ask Cursor in writing for the three dates the update does not give: when the Fireworks key was exposed, when the bucket was copied, and when the stolen credentials were first used.
- This site's suggestion: if you share data with a vendor, a read-only bucket still hands over whatever is in it. Scan for secrets before the data leaves, not after. Cursor says it added secret scanning across its repositories and expanded it to other internal data sources.
- This site's suggestion: if you run an extension marketplace, treat the cache that serves packages as its own trust boundary, separate from the registry that feeds it. Cursor says Open VSX never had the malware; the cache is where the copies were placed. Cursor also says it expanded network restrictions so a compromised credential cannot be used outside its intended location.
- This site's suggestion: keep a record of every credential you issue to a partner, its scope, its network limits and its expiry, so that when a partner reports an incident the question of which of your keys it held can be answered the same day.
The question the update leaves open
Cursor's update names a chain of six links and dates three points on it: 29 October, 1 November and 13 November. It does not date the exposure of the key, the copy of the bucket or the first use of the stolen credentials, and it does not say whether the key was deactivated before or after the attacker wrote to the cache. It gives a share of users, a share of customers and a ceiling on requesters, in three groups, with no base for any. If the credential that wrote to the marketplace cache came out of a bucket of old traces, when did it leave Cursor's hands, and why could a credential taken from a copy of customer traces change what 5,000 people received?
Sources
- PrimaryAn update on our recent security incident, dated Nov 13, 2026 (page header): the Fireworks key, the bucket of traces, the credentials, the SaaS tools, the 29 October cache write, the three figures, what was not affected and the steps taken. Saved by this site on 14 November 2026Cursoraccessed 2026-11-14
- PrimarySecurity notice, malicious version of Anthropic.claude-code (2.1.312 and 2.1.313) identified in the Cursor VS Code Extension Marketplace, dated Oct 29, 2026 with an edit line of Oct 30, 2026, 11:30 am PT: the window, the behaviour, the indicators. Saved by this site on 14 November 2026Cursoraccessed 2026-11-14
- PrimaryFireworks October 2026 security incident, last updated October 10, 2026, 11:16 PDT: environment variables in evaluation jobs captured in a limited number of customer accounts. Names no customer. Copy saved 10 November 2026Fireworks AIaccessed 2026-11-14
- PrimaryUpdate on October 2026 security incident, last updated November 9, 2026: a third-party cloud provider incident on 23 October, development machines reached on 24 October. Names no customer. Copy saved 10 November 2026Fireworks AIaccessed 2026-11-14
- PrimarySecurity bulletins index re-read on 14 November 2026 at 20:24 UTC: two bulletins, newest last updated November 9, 2026; nothing about CursorFireworks AIaccessed 2026-11-14
- Reported byCursor confirms security breach led to malicious Claude Code extension, 14 November 2026 12:27 ET (page data). A relay of Cursor's update that adds Wiz's Black October label and other companies; used only for those points and to show where its wording differs from Cursor'sBleepingComputeraccessed 2026-11-14
