Fireworks AI has disclosed a second security incident in less than a month, and the fallout has reached customers of companies that rely on its AI infrastructure.
In a Nov. 10 security update, the company revealed that attackers accessed its research and development machines through a compromised third-party cloud provider, exposing customer billing information, datasets, and subsets of incomplete AI model weights.
The expanded disclosure also has consequences beyond Fireworks itself. Notion has confirmed that some of its AI chat transcripts were caught up in the exposure, showing how a compromise at an AI infrastructure provider can extend to the businesses and users relying on its services.
The incident also raises broader questions about the security of third-party infrastructure providers, particularly those handling proprietary AI assets and sensitive customer information.
What is Fireworks AI
Fireworks AI is an AI infrastructure provider that helps developers and businesses run, fine-tune, and deploy AI models without building and managing the underlying computing infrastructure themselves.
Its customers range from AI startups developing products around large language models to established technology companies such as Notion, Cursor, Upwork, and Vercel, which use its platform to support AI-powered features.
That puts Fireworks in a dual position: it is a supply chain provider to businesses building AI products, while also depending on third-party providers for some of its own infrastructure.
This business model isn't an outlier in the technology industry. Still, it creates a security risk that, if not managed properly, can lead to the kind of third-party problems the security sector regularly witnesses, and is at the heart of this current incident.
A second attack in weeks
The company first detected unauthorized access on Oct. 6 and disclosed the incident on Oct. 9. Attackers accessed environment variables used in evaluation jobs for a limited number of customer accounts, exposing secrets such as API keys and access tokens.
But that was not the end of the story. In an updated security bulletin published on Nov. 9, Fireworks disclosed another intrusion, this time involving its research and development infrastructure.
According to the company, a third-party cloud provider hosting its R&D machines experienced a security incident on Oct. 23, which attackers used the following day to access Fireworks' systems.
The second incident expanded the company’s exposure. Attackers accessed resource metadata, billing and shipping addresses, invoices, payment histories, account balances, and credit usage. Some customers also had subsets of incomplete AI model weights and datasets exposed.
Fireworks clarified that it does not store payment card numbers, so those were not affected.
As for who is responsible, Fireworks says evidence from its investigation points to a financially motivated cybercriminal group interested in LLM-jacking. The company has not publicly identified the group by name, and the evidence does not establish that the same actors were behind both October incidents.
Fireworks has since brought in Palo Alto Networks' Unit 42 incident response team to assist with forensic investigations and security improvements, and has also notified law enforcement.
One breach opened the door to another, and another
The consequences of Fireworks AI's second security incident have extended into its customers' own operations, with some Notion customer data also exposed. Notion confirmed that fewer than 1% of its workspaces may have been affected.
The exposed records contained actual Notion AI conversations. Render CEO Anurag Goel shared a notification from Notion on X confirming that Render was among the affected customers.
Notion said most of the exposed transcripts lacked labels identifying their authors or originating workspaces, although the conversation content itself was accessible.

Some of Notion's customers were caught in the Fireworks AI breach. Image: Screenshot from X
That creates a downstream supply-chain problem. Fireworks relied on an external provider for some of its infrastructure, and compromising that provider gave attackers access to Fireworks' development environment. The resulting exposure then extended to data Fireworks processed for its own customers, which also affected its customers’ customers.
What defenders should do with this
None of this means businesses should stop relying on third-party vendors. There is a part of this partnership whose risk just cannot be fully eliminated, at least for now. Understanding that, however, should prompt businesses and defenders to plan for ways to protect themselves from the fallout when it happens.
That starts with a few practical steps:
- Limit what vendors can access: Give third-party providers only the permissions and data they need to deliver their services.
- Know what data they hold: Keep track of the customer records, credentials, datasets, and other information shared with each provider.
- Prepare to cut access quickly: Have a plan for revoking credentials, disconnecting affected services, and rotating exposed secrets.
- Know how to respond: Establish how vendors should notify you of an incident and how you can identify which of your data may have been affected.
- Always inform your customers of the third parties you use and the data these vendors hold about them: This can help your customers plan their security accordingly and choose whether they need to work with you.
These are established security practices, but the Fireworks incident shows why they remain important as AI services become more interconnected.
Organizations cannot eliminate every risk introduced by external providers. They can, however, reduce the likelihood that a compromise elsewhere in the supply chain becomes a larger incident for their own customers.
In other news, a new Black Kite report found that 34.2% of more than 18,000 AI suppliers have critical unpatched vulnerabilities, raising concerns about the security of third-party AI services and the potential risks to enterprise data and infrastructure.





