How the Fireworks AI breach widened from secrets to datasets

Fireworks AI’s security incident is larger than its first disclosure said. On October 9 the inference company reported that an intruder using internal Fireworks credentials had captured secrets stored in evaluation jobs for a limited number of customer accounts, and that it had found no evidence of access to customer models, datasets or personal information. Its November 9 update revises that picture. Fireworks now says account and billing information was affected, and that for a limited set of accounts the intruder also reached secrets, datasets and “incomplete models”.

The update adds two things the first bulletin lacked. The first is a second route in. A third-party cloud provider that hosted Fireworks research and development machines had its own incident on October 23, and on October 24 the intruder used it to reach Fireworks development machines and run an unauthorized workload. The second is an attribution. Fireworks says the evidence links the activity to a financially motivated group that sells tokens obtained through unauthorized access to large language models to illicit routing gateways, a practice it and Google’s threat researchers call “LLMJacking”. The visible part of the response is a product change. Self-serve dataset uploads and downloads for Batch Inference and dataset-based training are switched off, and Fireworks’ documentation now says Batch is paused and its stored datasets will be permanently deleted.

This article reconstructs the incident from the two Fireworks bulletins, the advisory published by one downstream customer, Notion, Fireworks’ own product documentation and the threat-intelligence reports that give the LLMjacking label its meaning. The Frontier Wire has not spoken to Fireworks, Notion or the investigators, and has no access to the forensic findings. Every claim below is attributed to the document that makes it.

The short version

• Stage one, detected October 6: internal Fireworks credentials were misused to read environment variables, including API keys and tokens stored as secrets, in evaluation jobs for a limited number of accounts.
• Stage two, October 23 and 24: a breach at an unnamed cloud provider hosting Fireworks R&D machines gave the intruder a path to development machines and an unauthorized workload that “led to additional customer data impact”.
• Fireworks now lists resource metadata, billing details and, for certain customers, datasets and a subset of incomplete model weights. It says card numbers were never stored and that Inference, Training SDK and Nexus show no detected impact.
• The attribution is to a type of criminal operation, not a named group. Fireworks has not published indicators or a threat-cluster designation.
• Notion says transcripts from its Insights feature were in the affected data for fewer than 1% of its workspaces.

The incident in one timeline

The table below merges every dated event in the primary documents. Fireworks gives times in Pacific Daylight Time for the first stage only. Events in the second stage carry dates without times. Notion’s entries come from its own advisory and describe what Fireworks told Notion, which is a different record from what Fireworks published.

Three intervals stand out. Fireworks needed about three and a half days from detection on October 6 to its first public bulletin, though customer notifications began the next morning. From the October 24 detection to the public update was 16 days. During that gap, Notion’s record shows Fireworks contacting at least one customer on November 2 and again on November 6 with a revised assessment. Public disclosure trailed private notification. That is common in incident handling, but it means the public bulletins are not a complete log of what customers knew and when.

The Google report’s date also needs care. When consulted for this article, the page header showed November 3, but the page’s structured metadata gives a publication date of November 2, which matches the date Fireworks cites. This publication uses November 2.

Stage one and the evaluation-job secrets

The first bulletin is short and specific: “On October 6, Fireworks identified a security incident involving unauthorized use of internal Fireworks credentials. An unauthorized third party accessed environment variables used in evaluation jobs in a limited number of customer accounts.” It continues that “environment variables, including API keys and tokens stored as secrets, were captured in certain affected accounts.”

Evaluation jobs ran customer-supplied evaluator code on Fireworks. The company’s documentation now groups evaluators with its retired managed reinforcement fine-tuning product, and says that on the Training API “your rollout code computes the reward for each sample” instead. Code of that kind can need credentials for outside services, for example a key to call another model as a judge or to reach a customer database. An archived copy of Fireworks’ “Using Secrets” page, captured on March 8, describes the mechanism: secrets created in the dashboard “will be injected as environment variables for your Evaluator to access.” That matches the bulletin’s description of captured environment variables, and the bulletin says Fireworks is “reviewing how secrets are made available to evaluation jobs.” The same documentation address now redirects to a page titled “Reinforcement Fine-Tuning (removed),” which states that “Evaluators and evaluation jobs have been removed too.” The documentation is undated and does not mention the incident, so this article does not treat the removal as part of the incident response. It does mean the surface where stage one happened no longer exists in its earlier form.

The October bulletin’s customer guidance carried the most useful technical warning in either document. It told affected customers to rotate any third-party credentials named in their notice “with the providers that issued them,” and added: “Removing a stored secret alone does not invalidate the underlying credential.” A secret stored on Fireworks might be an API key for a cloud account, a model provider or a database. Deleting it from Fireworks does nothing to the copy an intruder already holds. Only the issuing provider can revoke it.

That warning bears directly on the later attribution. The October bulletin did not mention motive. But a set of captured API keys and tokens for other services is exactly the raw material Google and Unit 42 describe LLMjacking crews collecting, as the attribution section below sets out. Whether any key captured from Fireworks was later used to resell model access is not stated in either bulletin.

The first bulletin also set the baseline that the update later revised. Fireworks wrote that it had “not detected evidence of unauthorized access to customer models, datasets, training data, personal information, or inference traffic within the Fireworks security perimeter or control.” The wording was hedged (“based on our investigation at this time”) and the review was described as ongoing. It was still a clear statement, and a month later it no longer held.

Stage two through a cloud provider

The update describes the second stage in two sentences: “A third-party cloud provider that hosted Fireworks R&D machines experienced a security incident on October 23. On October 24, the unauthorized third party used it to reach Fireworks development machines and then run an unauthorized workload that led to additional customer data impact.”

The wording carries several details. The phrase “the unauthorized third party” uses the definite article. Read plainly, it presents the October 24 intruder as the same actor as the October 6 intruder rather than a second, unrelated group. Fireworks does not say so outright, and it does not explain how stage one led to stage two, if it did. It does not name the cloud provider. BleepingComputer and The Hacker News, the two independent accounts read for this article, also leave it unnamed.

The provider hosted R&D machines, not the production platform. Yet the update says the workload run from development machines “led to additional customer data impact.” So some path existed from a development environment to a store of customer data. The update names that store only as “the affected internal application,” which it says “provided access to” the data categories listed in the next section. It does not say what the application was for, who normally used it or why it was reachable from development machines.

Fireworks says it “detected this activity on the same day” and “followed our incident response processes to take immediate remediation measures and close known critical vulnerabilities.” The phrase “known critical vulnerabilities” is not explained. It could mean software flaws, misconfigurations or excess permissions. The hardening list in the same update (credential lockdown, removing unnecessary elevated privileges, network isolation and tightened storage access) points to identity and access problems more than to a single software bug, but that is an inference from the remedies, not a finding Fireworks states.

The statement that “as of October 25, we have not detected further evidence of successful unauthorized access by the threat actor on the Fireworks platform customers use” deserves a close reading. It covers the platform customers use. It does not mention development or R&D environments, and it is dated October 25, 15 days before the update was published.

What data the intruder reached

The update lists three categories. The table compares them with the October bulletin and with Notion’s account of its own data. The status column records who is making each claim. “Fireworks states” means the company asserts it in a bulletin, and no independent party has confirmed it.

The list contains several gaps. Fireworks gives no count of affected accounts, only “a limited set.” It does not say which customers lost which category. Billing addresses and invoice histories are personal information for some customers, for example a sole developer billed at a home address, but the update does not discuss notification duties or regulators. It says only that Fireworks is “notifying customers whose data was impacted, and providing details about the impact and recommended response actions.”

“Incomplete model weights” is not defined. One plausible reading is intermediate training checkpoints. Fireworks’ Secure Training documentation says managed training retains intermediate checkpoints for 30 days so that jobs can be restarted. A subset of a model’s weight files is another plausible reading. Fireworks does not say which applies, and the difference matters. A complete checkpoint from mid-training can be a usable model. A fragment of one may not be.

The update also leaves the sequence unclear. It reports the discovery of account, billing, secret, dataset and model impact “since” the first bulletin. Separately, it says the October 24 workload “led to additional customer data impact.” It does not say whether the billing data and datasets were reached in stage one and discovered late, or reached for the first time in stage two. That matters for anyone judging whether the October 9 statement was wrong when it was made or was overtaken by a later intrusion.

How the account changed between bulletins

Set side by side, the two bulletins describe different incidents.

The scope row needs care. The update says “we discovered impacts to account and billing information” and then “for a limited set of accounts, we also discovered impact to secrets, datasets, and incomplete models.” The qualifier “limited set” attaches to the second sentence only. The update does not say whether the account and billing impact was broad or narrow. The Hacker News placed “limited set of accounts” at the end of a sentence listing both kinds of impact, which a reader could take to cover the billing data too. That is a fair reading of the second Fireworks sentence but not established for the first.

One press account also misplaced the attribution. BleepingComputer’s November 10 report, after describing the early-October incident, quotes the LLMjacking sentence as something Fireworks “said at the time.” In the copy of the October bulletin read for this article, last updated October 10, there is no attribution or motive. The sentence appears in the November 9 update. The difference changes the timeline. Fireworks first stated a criminal motive publicly a month after detection, not within days.

The attribution and what LLMjacking means

The full attribution sentence reads: “The evidence indicates links to a cybercriminal threat actor group, which is financially motivated and aimed at selling tokens from unauthorized access to Large Language Models (LLMs) to illicit routing gateways, known as ‘LLMJacking’.” Fireworks then points readers to the November 2 report by Google Threat Intelligence Group (GTIG) and Mandiant.

That report does not mention Fireworks. It describes incidents Mandiant responded to in 2026 across several cloud and LLM providers, affecting organizations in North America, South America and Asia Pacific in financial services, retail, technology and transportation. Its core model has two parts. One set of actors gains access to an organization’s cloud or model accounts. Another runs “LLM Mixers,” which GTIG describes as “illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers.” The phrase “illicit routing gateways” in Fireworks’ update echoes the GTIG report.

GTIG’s account of how these crews get in resembles the Fireworks facts in several respects. It says “the dominant initial access vector has been exposed or stolen cloud identity tokens,” naming IAM credentials, service account keys, GitHub personal access tokens and session tokens. After entry, actors “enumerated cloud services, code repositories, and data stores for sensitive credentials,” and in one case exfiltrated “third-party API keys from cloud secret managers.” Stage one at Fireworks, misused internal credentials leading to captured customer secrets, resembles that description. The update’s remedies, replacing service accounts and tightening controls on creating new credentials, address the persistence methods GTIG describes, such as unauthorized IAM and service accounts.

The report’s figures show why the economics attract criminals. They are GTIG’s observations across its own incidents, not measurements of this case. Mandiant observed fraudulent charges “exceeding $100,000 USD in a single day,” with cumulative charges at some organizations reaching $1 million before access was revoked. In one case, an actor made more than 500,000 LLM API calls in under eight hours with stolen third-party keys to power a token resale service, passing “nearly one million dollars in token costs” to the victim. Unit 42, the firm Fireworks hired, published a similar account on August 6. It describes gray-market “transfer stations” that resell discounted model access, often on stolen keys, and one case of nearly a million dollars in charges before containment. Unit 42’s report does not mention Fireworks either.

The attribution also leaves four things out.

• No named group. Fireworks gives no GTIG cluster designation such as the “UNC6993” used in Google’s report, and no indicators of compromise.
• “Links to,” not “conducted by.” The update says the evidence “indicates links to” such a group. That wording allows for a direct operator, an initial-access broker selling to one, or shared infrastructure.
• No reported resale. Neither bulletin says stolen keys were used to resell model access, or that any customer was billed for fraudulent use.
• No explanation for the data theft. Billing records and training datasets are not obvious LLMjacking targets, and Fireworks does not say why the actor took them.

One explanation for the last point is consistent with the GTIG material, but it is this publication’s inference and not a reported finding. Records of account balance and credit usage would show which accounts hold large prepaid balances or high spending limits, which is useful to an operator choosing accounts to drain. The datasets and weights may instead have been incidental to broad access, or taken for resale or extortion. Fireworks has published nothing that settles the question.

The response and the Batch shutdown

The update lists four hardening areas, carried out with Unit 42.

The “data protection” item says Fireworks “enforced controls designed to prevent public or unauthorized access to stored data.” The word “public” is notable, but the update does not say any stored data was publicly exposed. The bulletin uses the phrase “designed to prevent” throughout, which describes intent rather than verified effect.

The change customers will notice is in the next paragraph: “we’ve disabled self-serve dataset uploads and downloads used by Batch Inference and dataset-based training while we investigate this incident.” Batch Inference let customers upload a file of requests as a stored dataset, run a model over it asynchronously at a discount and download the results as another stored dataset. Fireworks’ Batch API page describes the old flow as uploading a JSONL file of up to 80 GiB, running a job and downloading an output dataset, at 50% of serverless per-token prices.

The documentation goes further than “while we investigate.” As consulted on November 12, the Batch page carries a warning: “Batch is paused. We’re moving to a more secure way of running Batch jobs. New Batch jobs are no longer accepted, dataset uploads return an error, and all Batch input datasets and job outputs stored on Fireworks will be permanently deleted.” The migration guide adds: “We will no longer support an async Batch dataset upload interface.” It directs customers to keep datasets locally and send each request themselves, with their own concurrency limits and retries, to a preemptible deployment, which it prices at 50% off on-demand rates. Preemptible capacity can be withdrawn mid-request without notice, according to the same guide.

So the bulletin describes a temporary suspension, while the documentation describes a retired interface and a deletion of stored data. Neither document dates the change or names the incident as its cause. The migration guide says only that Fireworks is “changing how Fireworks handles customer data for Batch.” The most cautious reading is that the incident prompted a suspension and Fireworks has since decided the stored-dataset model for Batch will not return. The documentation supports that reading, but Fireworks has not said it in a bulletin.

The design logic is easier to see in Fireworks’ retention documents. Its Zero Data Retention page says prompts and generations for open models “exist only in volatile memory for the duration of the request” and are not written to persistent storage. That is why the update can say Inference, Training SDK and Nexus, all “zero data retention (ZDR) by default,” show no detected impact. Uploaded datasets work differently. The Secure Training page says managed training datasets are “uploaded to Fireworks-managed storage (GCS),” while the Training API has “no dataset upload step and no dataset file stored on Fireworks’ side.” Batch inputs and outputs were likewise stored objects. Data that persists can be stolen later, and data that exists only in memory during a request cannot be stolen after it. Closing the stored-dataset path for Batch removes one store of the kind of data this intruder reached.

The update makes this argument for training: “Training SDK remains available with ZDR, i.e. no training data stored at rest, and Fireworks Lab-based training operates in an isolated environment with additional network and storage protection.” It does not describe Fireworks Lab, and this article does not try to.

Notion’s view from downstream

Notion’s advisory is the only first-party account from an affected customer found for this article, and it adds detail the Fireworks bulletins lack. Notion says it used Fireworks in two ways: “for classification jobs to help customers understand their own AI usage through a feature in Notion called Insights,” and “as a general inference provider to serve open-weight models inside our product.”

Its timeline shows the assessment changing. On November 2, Fireworks told Notion that “a small set of data had been accessed,” which Notion identified as “Notion AI synthetic testing data,” with “no Notion AI customer data” involved. By the morning of November 3, Notion had disconnected its systems from Fireworks and deleted all of its data there “out of an abundance of caution.” On November 6, Fireworks said “malicious actors may have accessed potential customer data.” Fireworks confirmed the final affected dataset on November 8, and Notion began contacting customers on November 9.

The final dataset “included Notion AI chat transcripts used for the Insights feature, which for the vast majority of impacted workspaces were unattributable.” Notion defines unattributable as “the chats weren’t labeled with who wrote them or which workspace they came from, and the transcripts did not contain tool call results.” It puts the impact at “<1% of Notion workspaces.” It has disabled Insights, stopped serving open-weight models through Fireworks, and advised affected customers to “treat this data as if it were exposed” and rotate any credentials pasted into Notion AI during the incident window.

Notion’s account answers one question the bulletins leave open. It shows what “datasets” meant for at least one customer: conversational data the customer had placed on Fireworks for a processing job. That is consistent with the stored-dataset explanation above. Notion does not say whether its classification jobs used Batch Inference specifically, and this article does not assume they did.

The Notion record also counters the idea that “unattributable” makes the exposure harmless. Notion itself says that beyond what is in the transcript “there’s no information tying the chat back to workspaces, users, or companies.” The qualifier matters. A transcript that quotes a company name, a project or a pasted credential can identify its author by its content, and Notion’s advice to treat the data as exposed and rotate pasted credentials points the same way.

Who should do what

The bulletins give little product-by-product guidance. The table below reads them against each Fireworks surface. It reflects this publication’s reading of the published documents and is not guidance issued by Fireworks. Customers should follow their own notice where they received one.

The October bulletin’s checklist still applies to any account in scope. It advised customers to review “API keys, users, evaluators, training jobs, and datasets” and report anything unrecognized, and offered secret names and credential fingerprints through a secure channel. GTIG’s report adds an LLMjacking-specific check: watch model gateway and API logs for small validation requests, such as calls with max_tokens=1, which it says actors use to test stolen keys before large-scale use. This publication’s guide to rate limiting and LLM token limits covers the spending caps and per-key quotas that limit how fast a stolen key can be drained.

What remains unknown

The investigation is ongoing by Fireworks’ own account, and these open questions decide how serious the incident turns out to be.

• How stage one began. Fireworks has not said how its internal credentials were obtained, or how long the intruder held them before detection on October 6.
• Whether the stages are connected. The update’s wording suggests a single actor but does not explain how the October 6 intrusion relates to the October 23 cloud-provider incident.
• The cloud provider. Its name, its own disclosure, if any, and whether its other customers were affected are all unknown.
• The size of the incident. No account count is given for any category, and none of the primary sources read for this article supplies one.
• What “incomplete models” means. Whether these were usable checkpoints or fragments determines whether the loss is of trained models or of partial files.
• Whether stolen keys were used. Neither bulletin reports fraudulent model usage billed to Fireworks customers or to the providers whose keys were stored as secrets.
• The basis for the attribution. “Evidence indicates links” is not explained. Indicators, tooling or infrastructure shared with known LLMjacking clusters would make the label testable.
• Whether Batch returns. The bulletin’s “while we investigate” and the documentation’s permanent deletion point in different directions.

Some evidence would change the conclusions here. A Unit 42 or Fireworks post-incident report naming the initial access vector and showing a link between the stages would turn the single-actor reading from an inference into a finding. Published indicators that match GTIG’s clusters would show whether this was LLMjacking in the full sense, with resale of stolen access, or a data theft by a group known for it. If affected customers reported fraudulent charges on keys taken from evaluation-job secrets, the incident would tie directly to the resale economy GTIG and Unit 42 describe. A disclosure from the cloud provider would show whether Fireworks was a target or one of several tenants exposed by a wider breach.

Why this incident matters beyond Fireworks

Inference providers hold more than prompts. A provider can promise and deliver zero retention on inference while storing customer secrets for evaluation code, datasets for batch and training jobs, intermediate checkpoints and billing records. The November update draws that line. The services with no detected impact were the ones Fireworks describes as zero data retention by default. The data that leaked was data Fireworks stored on a customer’s behalf, and in stage one it included credentials for other services.

That changes the usual question for anyone choosing an inference vendor. “Does the provider retain my prompts?” is not enough. The fuller question is which features cause the provider to store something for you, where that store sits and what can reach it. Fireworks’ own fix answers this in product terms. Customers keep datasets locally, the Training API receives only transient tokenized batches, and Batch’s stored-dataset interface is gone. This publication’s OWASP LLM Top 10 explainer treats unbounded consumption and supply-chain risk as separate entries. This incident touches both, because the provider is part of the customer’s supply chain and stolen credentials are what make unbounded consumption profitable for a criminal.

The disclosure record matters too. The first bulletin’s clear statement that no models, datasets or personal information had been accessed did not survive the investigation. That is not proof of bad faith. Early findings are often incomplete, and the October text was hedged. But the gap between private notifications to Notion on November 2 and November 6 and the public update on November 9 shows that a bulletin marked “Active monitoring” can lag what some customers already know. This publication made a related point about a different kind of report in its reading of the AISI incident and evaluation boundaries: a conclusion should stay at the level the published evidence permits. For Fireworks, the scope of the published evidence has already grown once, and the update says it “may reveal additional information.”