Fireworks AI: evaluation job secrets accessible after credential theft

Activity detected on October 6, 2026; bulletin issued on 9, updated on 10. Fireworks AI reports that a third party used internal credentials and reached evaluation job environment variables in a limited number of customer accounts. These variables could contain API keys and tokens provided by customers. The company has not detected, at the stage of its bulletin, any unauthorized access to models, datasets, training data, personal information or inference traffic within its scope. The nuance is crucial: access to secrets can open third-party systems, even if the data hosted at Fireworks is not declared read.

Why an evaluation job reads secrets

An evaluation job compares models or configurations and may need to call external APIs. To do this, the platform gives it keys as environment variables at run time. The service that orchestrates these jobs must therefore have the ability to read or inject secrets. If internal credentials give too broad access to this capacity, storage encryption is not enough: the platform may need to return the value in plain text to the authorized job, and the bad actor may attempt to reach the same path.

Fireworks does not publicly explain how the internal credentials were obtained or what specific API enabled the reading. It would therefore be wrong to publish a CVE, sandbox exploit or cross-client traversal as an established cause. The fact confirmed by the company is the unauthorized use of internal credentials and access to the variables of certain accounts; it says it is reviewing the way secrets are made available to evaluation jobs. This wording indicates a surface to reinforce, not a public patch diff.

Risk spreads outside the platform

An exposed key is not automatically used. If it is, its impact depends on the provider who issued it: inference charged, access to data, resource management or actions on a repository. Fireworks therefore asks affected customers to revoke credentials with third-party providers and then check their activity logs. Clearing a variable from the Fireworks interface does not revoke the key from its issuer. The bulletin also distinguishes Fireworks keys that it revoked itself from third-party keys for which customers are responsible.

The timeline given by Fireworks is useful: detection and start of containment on October 6, customer notifications on the 7th and 9th, employee key rotation on the 9th, then revocation of additional keys and tokens on the 10th. These dates show an evolving investigation. The lack of evidence of access to datasets or inference traffic “at this point” is not mathematical proof that no external systems accessible via a third-party key have been affected.

How to audit this boundary

An authorized audit would follow the life of a variable from its creation to the job, listing each service capable of reading it, the roles that can initiate an evaluation, the logs of this reading and the isolation between clients. It would test internal credentials with the principle of least privilege: should an account responsible for managing a job be able to read the secrets of another account? Rotation tests also demonstrate whether a revoked key actually becomes unusable at the issuing provider. No public PoC of the initial entry is published in the bulletin; This method is an audit framework, not a reproduction of the attack.

The incident reminds us that a secret stored in an AI platform retains all the rights that its issuer has given it. The response should correlate Fireworks logs with those of external suppliers and permanently limit the access of internal tools to client variables.

Primary source: Fireworks AI security bulletin.