VULNpocalypse
HighBreach / campaignMonitoring

Fireworks AI breach: internal credentials used to read secrets from customer evaluation jobs

Internal Fireworks AI credentials were used to capture secrets given to evaluation jobs in some customer accounts. Rotate listed credentials at the issuer.

Published
Updated
Exploitation
Yes. Fireworks says secrets were captured in affected accounts and the actor created its own Fireworks API keys

What happened

Fireworks AI is an inference and fine-tuning platform. Customers can store secrets in their account, and evaluation jobs receive environment variables, which can include those secrets. All timeline details below are from the Fireworks security bulletin, times in PDT:

  • 6 October 2026, 9:00: Fireworks identified the activity and began containment.
  • 7 October, 7:00: began notifying affected customers.
  • 9 October, 16:00: rotated Fireworks employee API keys.
  • 9 October, 18:00: notified the affected customers it had identified.
  • 9 October, 22:00: published the bulletin.
  • 10 October: revoked more Fireworks user API keys and rotated service-account tokens found in a completed credential review. Review and rotation continue; the bulletin’s status is “Active monitoring”.

How the attacker got in. Through “unauthorized use of internal Fireworks credentials”. Fireworks has not said how those credentials were obtained. Wiz lists credential access as the entry point (Wiz).

What was taken. The actor accessed environment variables used in evaluation jobs in “a limited number of customer accounts”. Fireworks believes environment variables, including API keys and tokens stored as secrets, were captured in certain affected accounts. The actor also created Fireworks API keys of its own, which Fireworks has since revoked (Fireworks).

What Fireworks says it has not seen. No evidence of access to customer models, datasets, training data, personal information, or inference traffic (prompts and outputs) inside its perimeter. Fireworks adds that it does not store prompts or outputs by default. It is still reviewing the calls made with the exposed credentials (Fireworks).

Not disclosed: the number of affected accounts, how the internal credentials were stolen, and the name of the outside security firm. Fireworks is reviewing how secrets are made available to evaluation jobs.

Fireworks was the first of the nine platforms in Wiz’s “Black October” count. Wiz reports that Fireworks saw signs of an “agent swarm” attack; the bulletin itself does not use that phrase (Wiz). See our Black October roundup for how stolen keys from these platforms were abused.

Am I affected?

Fireworks says that if you did not receive an affected-customer notice, no incident-specific action is needed (Fireworks). Check the inbox of every account owner and admin. If you are unsure which secrets were taken, Fireworks can send secret names and credential fingerprints over a secure channel.

If you were notified, take stock with firectl (Fireworks docs):

bash
# Secrets stored in the account: each one may have reached evaluation jobs
firectl secret list

# Every Fireworks API key in the account; look for keys no one recognises
firectl api-key list --all-users

# Datasets and training jobs you did not create
firectl dataset list
firectl supervised-fine-tuning-job list
firectl reinforcement-fine-tuning-job list

# Enterprise accounts: audit and data-access logs since September
# (--end is exclusive and dates are UTC)
firectl audit-logs list --start 2026-09-01 --end 2026-11-03 --no-paginate -o json

Audit logs, including data-access logs, are an Enterprise feature (Fireworks docs). Without them, check evaluators in the web console by hand.

Then, for each third-party credential named in your notice, pull that provider’s access logs from the day the secret was added to Fireworks up to today. Use after 6 October counts too, since the secret may have been copied.

What to do now

  1. Replace revoked Fireworks keys. Create new Fireworks API keys and update your apps; anything using a revoked key will fail authentication until you do (Fireworks).
  2. Rotate the listed third-party credentials at the issuer, then update your apps and the Fireworks secret. In Fireworks’ words, “removing a stored secret alone does not invalidate the underlying credential” (Fireworks).
  3. Review what those credentials could reach. Work with each provider to check for unauthorized reads, downloads or changes. Rotate even if you find nothing suspicious (Fireworks).
  4. Report unknown objects. Send the names or IDs of unfamiliar API keys, users, evaluators, training jobs or datasets to Fireworks by replying to your notice or writing to security@fireworks.ai (Fireworks).
  5. Trim what evaluators get. Give evaluation jobs only the secrets they actually call, with scoped, separate keys, so one exposed job does not hand over your main provider keys.

Sources