Fireworks AI Security Incident (October 2026): Billing Data and Some Datasets and Model Weights Affected, Company Says Cloud Provider Breach Was Involved. What Customers Should Do

The company says it is notifying customers whose data was impacted, with details and recommended response actions. Its October bulletin said that if you had not received an individual notice, it had not identified your account as affected and no action was required at that time. Check your spam folder too. If you received a notice, follow it first.

The contact is a reply to the notification email, or security-notice@fireworks.ai (November 9 update).

These are the steps in the October bulletin for customers who received a notice.

• Create new Fireworks API keys for any that were revoked and update the applications that used them (they fail authentication until updated)
• Rotate or revoke the third-party credentials named in your notice with the issuer, then update your applications and Fireworks secrets. Removing a stored secret alone does not invalidate the underlying credential
• With the issuer, review for unauthorized reads, downloads or changes. Rotate even if you find nothing suspicious

For key handling, see Environment variables and API keys basics.

In its November 9 update the company says that, for a limited set of accounts, datasets and a subset of incomplete model weights were accessed. Check whether your datasets held personal data, customer data, internal documents or keys, and if so, decide what to do under the rules that apply to each (our view).

The billing information that was affected is billing and shipping addresses, invoice and payment history, account balance and credit usage. These allow convincing fake invoices and payment confirmations to be written (a general point). Do not open links; open the company's dashboard yourself. More in What phishing is.

This is guidance from the October bulletin. Review API keys, users, evaluators, training jobs and datasets, and send the company the names or IDs of anything you do not recognize. The company says it has evidence indicating links to a financially motivated cybercriminal group. Also check for usage or charges you do not recognize (our view).

What to check in your own AI infrastructure and development environments in light of this incident is summarised below under "What operators of AI infrastructure should review".

In the company's account, a breach at a hosting provider became the way into development machines, and additional customer data was affected. Keep production customer data and credentials that reach production out of development and test environments, so that a breach of the host does not reach production (our view).

The first incident involved environment variables used in evaluation jobs. Pass a job only the secrets it needs, for a short time, and keep a read log. That way a leak of an internal credential does not expose a wide range of secrets at once (our view).

The company lists the categories as information the affected internal application could reach. Narrow permissions on internal systems that handle billing and customers' datasets by role, and keep development machines from reaching them directly (our view).

The company says Inference, Training SDK and Nexus are zero data retention by default and that no impact has been detected there. Data you do not store cannot be taken in a breach. Where a feature needs storage, such as datasets, keep it in a separate place and limit how long it is kept and who can reach it (our view).

The company describes the aim as selling access to AI models. Per-key usage limits, alerts on sudden jumps in usage and on calls from unusual places or times help you notice a stolen key in use (our view). Another case where API-key handling in AI infrastructure was the focus is The Northflank security incident.