Three Charged in $129M AI Voice-Cloning CEO Scam
On November 9, Fireworks AI updated its security bulletin to admit that the October breach it disclosed weeks earlier was worse than it first said. Considerably worse. Fireworks is the $17.5 billion, Nvidia-backed inference platform that serves open-weight models for customers including Uber, Shopify, and Doximity — the plumbing a lot of AI products run on top of without their own users ever hearing the name. The Information first reported the expanded disclosure, and CyberSecurityNews laid out the mechanics: a second, separate intrusion traced back to a hacked third-party cloud provider, and this time the attackers didn’t just touch credentials. They reached customer datasets, API secrets, and incomplete model weights.
Two breaches, five weeks apart, from the same company. That’s the detail that should bother you more than either incident alone.
Quick Summary: What Happened
Detail Info First incident Detected October 6, 2026 — misuse of internal credentials; customer notifications began October 7 Second, larger intrusion October 23–24, 2026 — a compromised third-party cloud provider hosting Fireworks’ R&D machines let attackers reach dev systems and run an unauthorized workload Expanded disclosure November 9, 2026, via Fireworks AI’s security bulletin Data exposed Resource metadata, billing/invoice/payment history, and — for a limited set of customers — secrets, datasets, and incomplete model weights Not affected Payment card numbers; Fireworks doesn’t store them Attribution Financially motivated “LLMjacking” actors who resell stolen LLM access through illegal routing gateways Named customers notified Harvey, per The Information; Notion and Cursor, per Bloomberg reporting Response Palo Alto Networks Unit 42 engaged for forensics; law enforcement notified Bottom line: The first Fireworks breach looked like a credential-leak cleanup job. The second one, run through a hacked cloud vendor, reached the datasets and model weights customers assumed were locked down — and Fireworks still won’t say how many customers that includes.
Start with the timeline, because the two incidents get conflated in a lot of the coverage and they’re genuinely different events with one shared root cause: attackers who didn’t go away.
Incident one, October 6. Fireworks detected misuse of internal credentials and began containment the same day. Customer notifications went out starting October 7. At the time, this read like a contained story — some secrets exposed, keys rotated, standard incident-response choreography.
Incident two, October 23–24. A third-party cloud provider hosting Fireworks’ research and development machines — Fireworks hasn’t named which one — suffered its own security incident on October 23. The next day, whoever was behind that compromise used it as a bridge into Fireworks’ dev environment and ran an unauthorized workload there. Fireworks says it found no further successful access after October 25.
That second intrusion is the one that actually matters, because of what sat on those development machines. According to Fireworks’ November 9 bulletin, the expanded exposure includes resource metadata (identifiers, display names, creation timestamps), full billing and invoice history, account balances and credit usage — and for a limited set of customers, secrets, datasets, and a subset of incomplete model weights. Payment card numbers were never in scope; Fireworks doesn’t store them.
“Incomplete model weights” is doing a lot of work in that sentence, and it’s worth being precise about what it does and doesn’t mean. It’s not a claim that finished, production-grade models walked out the door. It’s a claim that checkpoints, datasets, and training artifacts tied to in-progress customer work did. For a platform whose entire pitch is custom model fine-tuning and private deployment, that’s not a footnote — that’s the product.
Fireworks hasn’t published a customer count, and The Information reports the company “did not say how many customers were affected.” What has surfaced is partial. Legal AI company Harvey was among the large customers notified, per The Information’s sourcing. Bloomberg’s reporting adds Notion and Cursor to that list, with a Fireworks spokesperson confirming the company is “actively working with” affected customers to manage the fallout.
Notion’s own customer-facing explanation, which surfaced on Hacker News, is a useful look at how this cascades downstream: the company says fewer than 1% of its workspaces were affected, and that the exposed data included AI chat transcripts tied to its Insights feature — described by Notion as “unattributable” sessions without user labels. At least one affected customer pushed back on that framing in the same thread, saying the dataset they downloaded included a full, attributable chat tied to their workspace. Notion has since disabled Insights and stopped routing open-weight models through Fireworks. That’s the practical lesson sitting underneath the corporate language: when your vendor’s vendor gets breached, your customers find out about your product’s internals before you’ve finished your own investigation.
Fireworks doesn’t attribute the second intrusion to a nation-state or a ransomware crew. The November 9 update links it to a financially motivated group running “LLMjacking” — stealing LLM access and reselling the stolen capacity through illegal routing gateways, letting someone else’s AI bill fund a resale operation they never see. Google’s Threat Intelligence Group and Mandiant have been tracking this exact pattern for months, and their numbers give a sense of scale: single-day fraudulent charges topping $100,000, cumulative bills reaching $1 million before access gets revoked, and in one documented case, 500,000 API calls executed in under eight hours through a resale service called “Jet Night.” LLMjacking isn’t about reading your data for espionage. It’s about turning your compute budget into someone else’s product.
That framing changes what this breach actually is. A platform getting LLMjacked isn’t just a security embarrassment — it’s a business model collision. The attackers weren’t trying to steal Fireworks’ secrets for their own sake. They were trying to steal access to run inference at someone else’s expense, and the fact that they ended up with customer datasets and model weights along the way is a byproduct of how deep that access went, not the original goal.
It also matters that this is Fireworks’ second disclosure in five weeks, on a cloud-provider pivot the company still hasn’t named publicly. We covered a structurally similar failure mode with the LiteLLM supply-chain breach back in August — a trusted upstream dependency compromised, credentials harvested, and the blast radius extending to thousands of companies that had never heard of the actual point of failure. Fireworks is a different shape of the same problem: the weak point wasn’t Fireworks’ own application security. It was a third-party cloud vendor it trusted enough to host its R&D environment, with no public accounting yet of why that trust was warranted.
If you’re a Fireworks customer, or your product routes through one of theirs, this is a reasonable moment to actually check rather than assume you’re fine.
We’ve described Fireworks as a hosting option in our own coverage of open-weight models — it shows up as one of the go-to third-party API providers in our GLM-5 and DeepSeek V4 reviews, specifically because it saves teams from the headache of self-hosting. That advice doesn’t flip overnight because of one breach disclosure, even a bad one. But the pitch for using an inference platform instead of running your own infrastructure has always rested on the assumption that the platform’s security posture is better than what you’d build yourself. Two breaches in five weeks, the second one worse than the first, is the kind of data point that should at minimum reset how confident anyone is in that assumption.
There’s also a cost angle that’s easy to miss under the data-exposure headlines. LLMjacking turns stolen access into a direct financial drain, which is exactly the kind of risk our own AI cost-optimization coverage has mostly treated as a pricing and efficiency problem rather than a security one. After this, it’s both. An inference bill that spikes without warning isn’t automatically a usage surge anymore — it might be someone else’s resale operation running on your account.
Per Startup Fortune’s reporting, the expected customer reaction isn’t a mass exodus — it’s GPU scarcity keeping people put, paired with demands for audits, shorter data retention, and tighter access terms. That’s a realistic read of the market, not a cynical one. Switching inference providers mid-contract means re-benchmarking latency and re-migrating fine-tuned weights in a tight chip market, and that friction is real. It’s also exactly the kind of friction that lets a vendor absorb two breaches in five weeks without losing much business, which is its own separate problem worth sitting with.
The part of this disclosure that deserves more scrutiny than it’s gotten is the timing gap. Fireworks detected the first breach October 6, started notifying customers October 7, and seems to have believed — reasonably, based on what it knew then — that the story was a credential leak. The attackers who actually did the damage didn’t show up through Fireworks’ own systems at all. They came in through a cloud vendor seventeen days later, on October 23, and Fireworks still hasn’t named that vendor publicly. That’s not a knock on Fireworks’ incident response once the second intrusion was detected — notifying law enforcement and bringing in Unit 42 is the right playbook. It’s a question about why a platform hosting customer model weights and training data had R&D infrastructure sitting on cloud provider access broad enough that a breach somewhere else became a breach at Fireworks within 24 hours.
We’re not going to tell you to rip Fireworks out of your stack over this. The company’s response once each incident was detected looks competent, and the alternative — self-hosting every open-weight model your team wants to run — isn’t realistic for most organizations, which is exactly why platforms like this exist. But “competent incident response” and “trustworthy platform” aren’t the same claim, and this is the second time in five weeks Fireworks has asked customers to take the first on faith while it works out the second. If you’re evaluating any AI inference vendor right now — Fireworks or otherwise — the question to ask isn’t “did they respond well.” It’s “what does their cloud-provider dependency chain actually look like, and who’s accountable if that link breaks instead of theirs.”
Fireworks AI, an AI inference platform, disclosed two security incidents in late 2026. The first, detected October 6, involved misuse of internal credentials. The second, beginning October 23–24, traced to a compromised third-party cloud provider that let attackers reach Fireworks’ development machines. On November 9, Fireworks expanded its disclosure to confirm the second incident exposed billing records, API secrets, customer datasets, and incomplete model weights for a limited set of customers.
LLMjacking is an attack where criminals steal access to large language models — through leaked API keys, cloud credentials, or compromised infrastructure — and resell that access through illegal routing gateways, letting someone else’s compute budget fund their resale operation. Google’s Threat Intelligence Group and Mandiant have documented cases where this runs up fraudulent charges exceeding $100,000 in a single day.
No. Fireworks has confirmed it does not store payment card numbers, so those were not affected by either incident. Billing and invoice history — addresses, balances, and credit usage — was exposed, but not card numbers themselves.
Fireworks hasn’t published a full list or a customer count. Legal AI company Harvey was named in reporting from The Information as among the large customers notified. Bloomberg’s reporting adds Notion and Cursor. Notion has separately disclosed that under 1% of its workspaces were affected.
Incomplete model weights are partial checkpoints and training artifacts from in-progress work, not finished production models. Fireworks’ disclosure doesn’t claim complete models were stolen. But for customers using the platform to fine-tune proprietary models, exposure of in-progress training data and weights can still mean exposure of genuinely sensitive work.
Fireworks engaged Palo Alto Networks Unit 42 for forensics and notified law enforcement, which is the right response once an intrusion is found. Whether that’s “safe enough” depends on what you’re running through it — proprietary training data and fine-tuned weights carry more risk than stateless inference calls, and that’s the distinction worth making before your next renewal decision.
The LiteLLM breach was a software supply-chain attack — a compromised build dependency let attackers backdoor a package used by thousands of companies. The Fireworks incident is an infrastructure-pivot attack: a breach at an unnamed third-party cloud provider gave attackers a bridge into Fireworks’ own development systems. Different mechanism, same underlying lesson — the weak point in AI infrastructure security is rarely the product you’re evaluating directly.
Rotate any secrets issued through the platform, confirm directly with Fireworks whether your account falls within the affected customer set, audit any proprietary datasets or fine-tuning jobs you ran there, and check whether you owe your own downstream customers a notification — the way Notion did after learning its AI chat transcripts were part of the exposed data.
Last updated: November 10, 2026. Sources: Fireworks AI security bulletin · CyberSecurityNews · The Information, via MLQ.ai · Startup Fortune · Google Cloud Threat Intelligence: The Rise of LLMjacking · Palo Alto Networks Unit 42 · CNBC on Fireworks’ $17.5B valuation.
Related reading: The LiteLLM Breach Just Hit 2,500 AI Tool Stacks · GLM-5 Review · DeepSeek V4 Review · AI Cost Optimization Guide · OpenAI’s AI Hacked Hugging Face — Then It Paused Astra