On 9 October 2026, the AI inference and model training platform Fireworks AI published a security bulletin saying an unauthorised party had used internal Fireworks credentials to read environment variables used in evaluation jobs in a limited number of customer accounts. Fireworks identified the activity on 6 October 2026 and began containment the same morning. It believes API keys and tokens that customers had stored as secrets were captured in certain accounts. Fireworks says it has found no evidence so far of access to customer models, datasets, training data, inference traffic or personal information. It has revoked the internal credentials, the affected Fireworks API keys and keys the actor created, rotated employee API keys and service-account tokens, and brought in an outside security firm. Fireworks has not said how its internal credentials were obtained or how many customers were affected. The Cloud Security Alliance groups the incident with the OpenCode and Railway breaches of October 2026, while noting no vendor has linked them to one actor.
Key takeaways
- Fireworks AI says an unauthorised party used internal Fireworks credentials to access environment variables in evaluation jobs for a limited number of customer accounts, detected on 6 October 2026 and disclosed publicly on 9 October.
- Fireworks believes customer API keys and tokens stored as secrets were captured. These are third-party credentials, so the exposure reaches beyond Fireworks to whatever services those keys unlock.
- According to Fireworks, there is no evidence so far of access to models, datasets, training data, inference traffic or personal information, and it does not store prompts or outputs by default.
- Fireworks revoked internal credentials, affected API keys and keys the actor created, then rotated employee API keys and service-account tokens. How the internal credentials were obtained has not been disclosed.
- The identity lesson: a platform that runs customer jobs holds customer secrets, and its own internal credentials become a key to all of them. Deleting a stored secret does not revoke it; only the issuer can.
At a glance
| Organisation | Fireworks AI, and a limited, undisclosed number of its customer accounts |
|---|---|
| When | Activity identified 6 October 2026; affected customers notified from 7 October; public bulletin 9 October 2026, updated 10 October |
| Attacker | Unknown. Fireworks describes an unauthorised party; no actor has been named and no vendor has linked the incident to another breach |
| Entry point | Internal Fireworks credentials used without authorisation; how they were obtained has not been disclosed |
| Identities abused | Internal Fireworks credentials, then customer API keys and tokens stored as secrets in evaluation job environment variables; Fireworks also revoked API keys the actor created |
| Impact | Customer third-party API keys and tokens believed captured in certain accounts; no evidence so far of access to models, datasets, training data, inference traffic or personal information |
| Category | NHI, LLM / AI platform. Incident class: confirmed NHI breach (internal credentials abused to read customer secrets) |
What happened
Fireworks AI runs a platform for serving and fine-tuning AI models. Customers can run evaluation jobs on it, and those jobs can be given secrets, such as API keys for other services, through environment variables. That convenience means the platform holds credentials that belong to its customers' wider estates, not just to Fireworks.
According to the Fireworks bulletin, an unauthorised party used internal Fireworks credentials and accessed environment variables used in evaluation jobs in a limited number of customer accounts. Fireworks believes API keys and tokens stored there as secrets were captured in certain accounts. It identified the activity at 9am Pacific time on 6 October 2026 and began containment straight away. It started notifying affected customers on 7 October, rotated Fireworks employee API keys on the afternoon of 9 October, notified the customers it had identified that evening and published the bulletin at 10pm Pacific time. On 10 October it revoked further user API keys and rotated service-account tokens, and it says credential review and rotation are continuing.
Fireworks says it has found no evidence of unauthorised access to customer models, datasets, training data, inference traffic or personal information within its security perimeter, and that it does not store prompts or outputs by default. It is still reviewing calls made with the exposed credentials. As well as revoking the internal credentials and affected keys, it revoked API keys the actor had created, added access restrictions, is reviewing how secrets are supplied to evaluation jobs and is working with an outside cybersecurity firm. The bulletin's status was "Active monitoring" at its last update. Fireworks has not said how the internal credentials were obtained, whose credentials they were, or how many customers were affected.
The Cloud Security Alliance, in a research note of 23 October 2026, places Fireworks alongside the OpenCode Console breach 2026 and the Railway breach 2026 because of a shared pattern and timing: attackers going after the AI provider keys that developer platforms hold for their users. CSA is careful on attribution: "No vendor has publicly linked these incidents to a single actor." Helix, in a round-up published on 31 October, counts Fireworks among nine AI developer platforms breached that month. Other October cases include the Northflank breach 2026 and the TiDB Cloud breach 2026.
Timeline
| Date | Event |
|---|---|
| 6 October 2026 | Fireworks identifies unauthorised activity at 9am PDT and begins containment. |
| 7 October 2026 | Fireworks starts notifying affected customers. |
| 9 October 2026 | Fireworks rotates employee API keys, notifies the customers it has identified and publishes its security bulletin at 10pm PDT. |
| 10 October 2026 | Fireworks revokes additional user API keys, rotates service-account tokens and updates the bulletin; review and rotation continue. |
| 23 October 2026 | The Cloud Security Alliance publishes a research note grouping Fireworks with the OpenCode and Railway disclosures, without attributing them to one actor. |
| 31 October 2026 | Helix lists Fireworks among nine AI developer platforms breached in October 2026. |
How it happened: the identity attack path
- Internal credentials obtained. The attacker gained internal Fireworks credentials. Fireworks has not said how, and CSA notes the method is not stated.
- Platform access as Fireworks. Using those credentials, the attacker could reach evaluation job configuration across customer accounts, a view a customer's own credentials would not give.
- Secrets read from job environments. The attacker read environment variables supplied to evaluation jobs in a limited number of customer accounts, where customers had stored third-party API keys and tokens as secrets.
- Persistence through new keys. Fireworks says it revoked API keys the actor created, which shows the attacker issued fresh credentials of its own on the platform.
- Containment by revocation. Fireworks revoked internal credentials, affected and attacker-created keys, rotated employee API keys and service-account tokens, and left customers to rotate third-party secrets with each issuer.
Impact
- Confirmed: Unauthorised use of internal Fireworks credentials and access to evaluation job environment variables in a limited number of customer accounts. Fireworks believes API keys and tokens stored as secrets were captured in certain accounts.
- Not found so far: According to Fireworks, no evidence of access to customer models, datasets, training data, inference traffic or personal information. Its review of calls made with the exposed credentials is ongoing.
- Potential: Any third-party service whose key sat in an affected evaluation job is exposed until that key is rotated at the issuer. Fireworks advises customers to rotate even if they see nothing suspicious.
- Unknown: The number of affected customers, which providers' keys were involved, and how the internal credentials were obtained have not been disclosed.
- Wider: CSA and Helix both place the incident within a month of attacks on AI developer platforms whose prize was the AI provider keys those platforms hold for customers.
What this means for NHI and AI agent security
This is an NHI breach from end to end. The way in was an internal machine-usable credential, the target was customer API keys and tokens, and the clean-up was revocation and rotation of employee API keys, user API keys and service-account tokens. No human account takeover is described. It belongs on an NHI list because it shows how secrets pool on AI platforms: every customer who passes a provider key into an evaluation job hands the platform a copy, and a single internal credential can then unlock many of them.
The lesson for customers is the one Fireworks puts plainly in its guidance: removing a stored secret does not invalidate the credential. Only the issuer can revoke a key, which is why our Leaked Credential Response Playbook and Secrets Rotation Runbook Template start at the source. The lesson for platforms is that internal credentials with cross-tenant reach are among the most sensitive NHIs they own, and they need the scoping, monitoring and short lifetimes set out in our Secrets Management Guide. Keys stolen this way usually end up running up bills on AI providers, a pattern covered in our LLMjacking Guide.
Recommendations
- Rotate exposed keys at the issuer. If you received a Fireworks notice, create new Fireworks API keys, then rotate every third-party credential listed in it with the provider that issued it. Deleting the secret from the platform is not enough. See our Leaked Credential Response Playbook.
- Review provider logs for the exposed keys. Check each provider for unauthorised reads, downloads, usage spikes or configuration changes from the exposure window onwards, and rotate even when nothing looks wrong. See our LLMjacking Guide.
- Hunt for resources you did not create. The attacker created its own API keys. Look for unknown API keys, users, evaluators, training jobs and datasets in your account, and report them.
- Give platform jobs scoped, short-lived secrets. Pass evaluation and build jobs keys that are limited to the task, capped on spend and rotated often, rather than long-lived production keys. See our Environment Variables and .env Files guide.
- Treat cross-tenant internal credentials as crown jewels. Platforms should keep staff and service credentials that can read customer secrets to a minimum, bind them to strong authentication and alert on any bulk read. See our Secrets Management Guide.
- Keep a register of where each key lives. Know which platforms hold copies of each AI provider key so a single vendor notice can be turned into a rotation list in minutes. See our Secrets Rotation Runbook Template.
Frequently asked questions
What happened in the Fireworks AI security incident?
Fireworks AI disclosed on 9 October 2026 that an unauthorised party used internal Fireworks credentials to access environment variables in evaluation jobs for a limited number of customer accounts. It believes API keys and tokens stored there as secrets were captured. Fireworks found no evidence so far of access to models, datasets, training data, inference traffic or personal information.
Do Fireworks AI customers need to rotate their API keys?
Customers who received a Fireworks notice need to replace revoked Fireworks API keys and rotate every third-party credential named in the notice with its issuing provider, because removing a stored secret does not invalidate it. Fireworks says customers who received no notice have not been identified as affected so far and need take no action at present.
How did the attacker get Fireworks AI's internal credentials?
Fireworks has not disclosed how the internal credentials were obtained, and the Cloud Security Alliance notes that the method is not stated. Fireworks is working with an outside cybersecurity firm and says its credential review is ongoing. No actor has been named.
Related NHI Mgmt Group resources
Railway breach 2026 · OpenCode Console breach 2026 · Northflank breach 2026 · Secrets Management Guide · LLMjacking Guide
How NHI Mgmt Group can help
The Fireworks incident turns on two NHI problems most organisations have not solved: knowing which platforms hold copies of their API keys, and making sure internal credentials with broad reach are scoped, watched and short-lived. Our NHI Foundation Level training covers secrets inventory, rotation at the issuer and incident response for exposed keys, and our advisory team helps platform and customer teams build those controls in. See our NHI and AI agent security training.
References
- Fireworks AI: October 2026 security incident (9 October 2026)
- Cloud Security Alliance: Inference Providers as the Prize: Platform-Chain Campaigns Against AI Serving (23 October 2026)
- Helix: Black October: The AI Developer Platform Breaches of October 2026 (31 October 2026)