If your team trained, evaluated or batch-ran anything on Fireworks AI, treat every secret you stored on the platform as exposed and rotate it at the issuing provider this week. Fireworks' November 9 incident update widens an October breach that first looked limited to evaluation-job secrets. It now covers billing information for affected accounts, a subset of incomplete model weights and datasets for certain customers, and secrets, datasets and incomplete models for "a limited set of accounts." Fireworks says inference, its Training SDK and Nexus show no impact, because all three run with zero data retention by default.
The practical lesson reaches past one vendor. Anything you park at a hosted training or evaluation provider (a dataset, a checkpoint, an API key for an LLM judge) is now data a criminal group has shown it wants, and the October wave of AI platform breaches shows it can get it.
What Fireworks Says Was Accessed
Fireworks now says the attacker reached billing records, stored secrets, datasets and partial model weights, which goes well beyond the evaluation-job environment variables it disclosed in October. The November 9 update lists four categories:
- Resource metadata: identifiers, display names, descriptions and creation times.
- Billing information: billing and shipping addresses, invoice and payment history, account balance and credit usage. Fireworks says it does not store payment card numbers and that none were affected.
- For certain customers, a subset of incomplete model weights and datasets.
- For a limited set of accounts, secrets, datasets and incomplete models.
"Incomplete" matters, but less than it sounds. A partially trained checkpoint of a model fine-tuned on your support tickets or contracts still encodes some of that data, and the dataset that produced it is the raw material itself.
The timeline covers two separate incidents. The original bulletin says Fireworks identified unauthorized use of internal credentials on October 6, began notifying customers on October 7, and published on October 9. In that first incident, an attacker read "environment variables used in evaluation jobs" in a limited number of accounts, and Fireworks believed API keys and tokens customers had stored as secrets were captured. At the time it said it had found no evidence of access to customer models, datasets, training data or inference traffic.
The second incident is the reason for the new update. Per Fireworks, a third-party cloud provider hosting Fireworks R&D machines had a security incident on October 23. On October 24 the unauthorized party used that access to reach Fireworks development machines and ran an unauthorized workload, which caused the additional customer data impact. Fireworks says it detected that the same day.
What Is Still Unknown
The bulletin does not name the entry point's owner, the threat actor or the number of affected customers, and Fireworks says the investigation "may reveal additional information." It does not identify the third-party cloud provider. It does not describe the full scope of what was taken from the "limited set of accounts." It does not publish the recommended response actions it is sending to notified customers; those go out privately by email.
What it does say is that its evidence links the activity to a financially motivated cybercriminal group that sells LLM tokens obtained through unauthorized access, a practice it calls LLMJacking. It also says it has notified law enforcement, has revoked and replaced credentials, removed unnecessary elevated privileges, restricted network paths and tightened data storage access.
Plan on the scope growing. It already grew once, between the October 10 version of the bulletin, which found no evidence of dataset or model access, and the November 9 version, which found both.
What Fireworks Has Switched Off
Self-serve dataset uploads and downloads for Batch Inference and dataset-based training are disabled while the investigation runs, according to the update. The Training SDK remains available under zero data retention, and Fireworks says training through its Lab runs in an isolated environment with added network and storage protections.
The product surface has also changed. Fireworks' documentation page for managed reinforcement fine-tuning now says "Managed reinforcement fine-tuning has been removed" and that evaluators and evaluation jobs have been removed as well; reward computation moves into your own rollout code on the Training API. The page does not say why, and nothing in the bulletin ties the removal to the incident. Either way, any pipeline that depended on hosted evaluators, and on the secrets those evaluators read, needs a new home.
If you have a batch job or a scheduled fine-tune that uploads a dataset, check it now. It is probably failing.
Who Is Behind LLMJacking and What They Want
LLMJacking is the theft and resale of access to large language models, and the Fireworks bulletin points at a group that does exactly that. Google Threat Intelligence Group and Mandiant described the trade in a November 2 report. Mandiant says it responded to incidents where fraudulent charges exceeded $100,000 in a single day, and cumulative charges reached $1 million at some organizations before access was revoked. One actor ran more than 500,000 LLM API calls in under eight hours.
The report describes a division of labour: initial access operators steal cloud tokens and API keys, and "LLM Mixers" pool and resell that access. One token-routing service it names offered an unlimited plan for about $60 a month against a typical market rate of $100 to $250, which Google's researchers believe only works on stolen keys. The Google report does not mention Fireworks; the link to LLMJacking is Fireworks' own assessment.
That motive explains why secrets were the first target. A Fireworks evaluation job that called an outside model as a judge needed that provider's key, and the key was sitting in an environment variable.
Fireworks Was One of at Least Nine
Fireworks heads a list of at least nine AI developer platforms that reported incidents in October, and the pattern across them is attackers hunting stored credentials. Wiz's "Black October" tracker, published October 30 and updated through November 10, lists Fireworks, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank, and has since added more, including NVIDIA's Brev, Trigger.dev, Chainstack and Tensorlake. In two cases Wiz investigated, stolen enterprise Amazon Bedrock credentials produced about 800,000 calls over roughly 30 hours and about 1.7 million over roughly 13 hours, more than $100,000 of usage at list price. Wiz says no single vulnerability links the attacks and does not tie Fireworks to the Bedrock abuse. It does note that Notion reported downstream impact from the Fireworks incident.
The Cloud Security Alliance's November 4 research note puts the shared lesson plainly: deleting a key from a breached platform does not revoke it, only the issuing provider can, and key scoping slowed abuse without stopping it. Its October 23 note calls this a platform-chain pattern. A single production key may be copied into a PaaS environment, a gateway database, an evaluation platform and a CI system at once, so its real protection is that of its weakest copy.
The open-model ecosystem is feeling the pressure. Hugging Face's chief policy officer Irene Solaiman told TechCrunch that open platforms are "prime targets," and the article says continued attacks could push them toward upload limits, identity verification and developer vetting. The same article notes the Fireworks attack is not necessarily tied to openness, but shows how much valuable data sits with AI infrastructure providers.
Which Fireworks Data Was Protected, and Why
The products that held nothing were the ones Fireworks says were unaffected. Its data handling documentation says Fireworks "does not log or store prompt or generation data for any open models, without explicit user opt-in," and enterprise admins can turn on a zero data retention policy that rejects requests and jobs that would persist customer content. Serverless and dedicated inference ran that way, and the bulletin reports no impact there.
Training is different by design. Fireworks' secure fine-tuning page says standard managed training uploads datasets to Fireworks-managed storage, and checkpoints are kept for 30 days so jobs can restart. The same page offers two controls that shrink what a provider holds. Bring-your-own-bucket keeps the dataset in your GCS or Azure bucket, read in place with no copy persisted, and you can remove the IAM binding after the job. Customer-managed encryption keys let you revoke the key Fireworks uses to decrypt stored datasets and checkpoints. Fireworks does not say which plans include either, and neither covers a secret pasted into a job's environment.
Every hosted fine-tuning service makes this trade. If you want a vendor to train for you, it needs your data. Whether it keeps a copy after the job finishes is a term you can negotiate, and most teams never ask. Our zero data retention comparison shows how much those terms vary across providers, and fine-tuning's monthly hosting fees mean weights tend to sit at the vendor long after training.
What to Do About It
Rotate first, then shrink what you leave at any training or evaluation vendor. If you use Fireworks AI, Together AI, Baseten or anyone else that runs jobs on your behalf, the same steps apply.
This Week:
- Rotate every credential you ever stored as a Fireworks secret, at the provider that issued it. Fireworks' October guidance says removing a stored secret does not invalidate the credential. Start with model provider keys (OpenAI, Anthropic, Bedrock, Vertex), then cloud and database credentials.
- Find your notification. Search the inbox of every Fireworks account owner and billing contact for the incident email, and reply to it or write to security-notice@fireworks.ai if you are unsure whether you were affected.
- Pull billing and usage logs from each provider whose keys lived on Fireworks, going back to October 1, as the CSA note recommends. Look for first calls from unfamiliar networks and single validation calls.
- In your Fireworks console, check for API keys, users, training jobs and datasets you do not recognise, per the October bulletin.
- Fix the batch and training jobs broken by the dataset upload freeze, or pause them deliberately rather than letting them retry.
This Month:
- List every model, checkpoint and dataset you have stored at Fireworks. Decide with the data owner whether anything regulated or confidential was in it, and bring in legal if your contracts or privacy notices require you to tell anyone.
- Delete datasets and checkpoints you no longer need from every hosted training vendor, and record what you keep and why.
- Set hard spending caps and per-model quotas on every LLM key, as both the Google report and CSA advise. Issue one key per platform so a single breach is a single rotation.
Before Renewal:
- Ask every inference and training vendor whether it supports bring-your-own-bucket and customer-managed keys on your plan, and get the answer in writing.
- Ask how secrets are exposed to jobs, who can decrypt them, and how fast they notify you. Our AI vendor security review questions are a starting list.
- Require zero data retention for inference contractually, and a stated retention period for anything you upload for training.
The Bigger Picture
AI infrastructure vendors are now custodians of three things attackers resell: model keys, training data and the weights trained on it. The cloud went through this a decade ago, when leaked access keys in public repositories became a standing source of cryptomining bills and providers responded with secret scanning and default spending alerts. The same correction is starting here. Fireworks has moved inference and training toward zero retention, Hugging Face told TechCrunch it now rotates admin tokens more often, and the October breaches give every buyer a reason to ask what a vendor keeps and for how long.
We covered the key-rotation side of this wave in our Black October breakdown and the LiteLLM 1.107.0 compromise. Fireworks adds training data and weights to that list. Rotate the secrets today, then delete the datasets you no longer need.
Continue Reading
- Rotate Your Bedrock Keys If You Used These Nine AI Platforms
- LiteLLM's October 21 Compromise Puts Provider Keys at Risk
- An Eval Sandbox Gave Up Its Keys. Your Gateway Holds Yours.
- Use Bedrock's None Mode to Enforce Zero Data Retention
- AI Vendor Security Review: 6 Questions That Change the Answer
- Together vs Fireworks vs Groq: Fireworks Leads Moonshot's Audit