Fireworks AI Hit Twice in Weeks: 10,000+ Customers [2026]

Fireworks AI disclosed a second security incident in three weeks, stating in its security bulletin that a third-party cloud provider hosting its R&D machines suffered a breach on October 23, 2026, after which an unauthorized third party reached Fireworks development machines on October 24 and ran an unauthorized workload. Fireworks said the affected data includes resource metadata, billing information and, for certain customers, a subset of incomplete model weights and datasets, while payment-card numbers were not stored by Fireworks and were not impacted; a Fireworks spokesperson told Bloomberg the company is "actively working with our customers to manage the incident, including Notion, Cursor and others." The earlier incident dates to October 6, 2026, when Fireworks identified unauthorized use of internal credentials, and the company has not published customer or file counts.

Fireworks AI, the Nvidia-backed inference platform used by developers to run open models at scale, has disclosed a second security incident within weeks of its first. Bloomberg reported that the company is notifying customers after an unauthorized third party reached its research-and-development machines. The Fireworks AI hack stems from a third-party cloud provider that suffered its own incident on October 23, 2026. The earlier episode dates to October 6, when Fireworks identified unauthorized use of internal credentials. Coverage from Bloomberg, The Information, BleepingComputer, Startup Fortune and MLQ.ai has since filled in the outline, though the company has not published customer counts or file counts. That gap matters, because the story now turns on what is confirmed and what is still rumor. For engineers, the practical question is simple: what secrets, weights and datasets sat inside the blast radius? Leaked credentials in developer tooling are a pattern we have tracked before, including the 1,379 secrets exposed on GitHub through Claude Code settings files https://shattered.io/claude-code-settings-local-json-1379-secrets-github-2026/ . This analysis separates what Fireworks said on the record from what remains unconfirmed, then maps the fallout for customers, competitors and the wider AI infrastructure market. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F What Fireworks Confirmed About Its Second Hack Start with the company’s own words. In its security bulletin, Fireworks wrote: “A third-party cloud provider that hosted Fireworks R&D machines experienced a security incident on October 23.” That sentence places the origin of the second incident outside Fireworks’ own walls, at a provider that hosted its research-and-development machines. The bulletin goes on to say that on October 24, 2026, an unauthorized third party reached Fireworks development machines and ran an unauthorized workload. Fireworks listed the data it has identified as affected: resource metadata, billing information, and, for certain customers, a subset of incomplete model weights and datasets. It also said payment-card numbers were not stored by Fireworks and were not impacted. One line in the update deserves a close read. Fireworks said that as of October 25, 2026, it had not detected further evidence of successful unauthorized access to the customer-facing Fireworks platform. The phrasing is narrow on purpose. It speaks to the production platform, not to the R&D machines where the intrusion did occur, and it speaks to evidence detected so far rather than to a finished forensic review. On notification, Fireworks said it directly notified every identified affected customer in the first incident. For the expanded second incident, it said it is notifying customers whose data was impacted. A Fireworks spokesperson told Bloomberg the company is “actively working with our customers to manage the incident, including Notion, Cursor and others.” Timeline: October 6 to Today The dates are tight. Seventeen days separate the first incident from the third-party cloud provider’s trouble, and the whole sequence from first detection to the latest status update fits inside three weeks. Today is November 10, which means customers have had roughly two weeks since Fireworks’ last stated status checkpoint. The table below lays out the sequence as Fireworks and the press have described it. | Date 2026 | Event | Source | |---|---|---| | October 6 | Fireworks identifies unauthorized use of internal credentials | Fireworks security bulletin | | October 23 | Third-party cloud provider hosting Fireworks R&D machines suffers a security incident | Fireworks security bulletin | | October 24 | Unauthorized third party reaches Fireworks development machines and runs an unauthorized workload | Fireworks security bulletin | | October 25 | Fireworks reports no further evidence of successful unauthorized access to the customer-facing platform | Fireworks security bulletin | | Late October to now | Bloomberg reports Notion, Cursor and others among customers being worked with | Bloomberg | | November 10 | Customer counts, file counts and weight volumes remain undisclosed | Reporting to date | Notice what the timeline lacks. In the published material, there is no stated end date for the intrusion, no statement on how long the unauthorized workload ran, and no description of what that workload did. Each missing item is a question customers will put to Fireworks in their next security review. Incident One: Internal Credentials and Evaluation Variables The October 6 incident started with unauthorized use of internal credentials. Fireworks said that environment variables used in evaluation jobs were accessed in a limited number of customer accounts, and that those variables could contain secrets. The company has not said how many accounts fall into that limited group. Taken alone, this first Fireworks AI security incident is the more conventional of the two events. Internal credentials get misused at many companies, and the usual fix is revocation, rotation and a review of access logs. What sets it apart is the target. Evaluation jobs sit close to a customer’s model work, so their environment variables often hold keys that reach other systems. Why Environment Variables in Eval Jobs Matter Teams routinely pass API keys, storage tokens and webhook URLs into evaluation jobs through environment variables, because it is the fastest way to give a job access to a test set or a judge model. Fireworks’ warning that the variables could contain secrets is therefore not a formality. Any key that ever lived in such a variable should be treated as exposed if the account was in the affected group. A quick audit helps teams find where secrets might hide. The command below is a starting point for scanning a repository for evaluation configs that reference keys. git grep -nE " API KEY|SECRET|TOKEN|PASSWORD " -- " .yaml" " .yml" " .env " " eval " Anything the scan surfaces should be rotated if it was ever passed to an affected account. Fireworks said it directly notified every identified affected customer in this first incident, so a customer who received no notice has some reason for comfort, though not proof of safety. Incident Two: A Cloud Provider Hosting the R&D Machines The second incident came through a supplier. Fireworks said a third-party cloud provider that hosted its R&D machines experienced a security incident on October 23, and the next day an unauthorized third party reached Fireworks development machines. The security bulletin, as quoted in coverage, does not name the provider, and we have seen no confirmed identification. This is a supply-chain story as much as a breach story. A company can harden its own accounts, rotate its own keys and still lose control of machines it rents. The hosting provider’s incident gave the intruder a path onto Fireworks hardware that Fireworks did not directly operate at the network layer. What an Unauthorized Workload Could Mean Fireworks said the third party ran an unauthorized workload. The company has not described the workload, so any reading is inference. In general, an unauthorized workload on research machines can mean data collection, credential harvesting, or compute theft. GPU-rich R&D hosts are attractive for the third purpose alone. Fireworks did list data it identified as affected, which suggests the intruder touched stored information and not only compute. Until the company publishes a technical write-up, customers should not assume the workload was benign. They also should not assume the worst. The honest position is that the workload’s purpose is unknown. What Data Fireworks Says Was Affected Fireworks grouped the affected data into three buckets. The first is resource metadata, which includes resource identifiers, display names, descriptions and creation times. The second is billing information, including billing and shipping addresses, invoice and payment history, account balance and credit usage. The third, limited to certain customers, is a subset of incomplete model weights and datasets. | Data category | What Fireworks said | Why it matters to customers | |---|---|---| | Resource metadata | Identifiers, display names, descriptions, creation times | Names and descriptions can reveal project codenames and product plans | | Billing information | Billing and shipping addresses, invoice and payment history, account balance, credit usage | Supports phishing and invoice fraud, and shows spending scale | | Model weights and datasets | For certain customers, a subset of incomplete weights and datasets | Possible intellectual property exposure, though “incomplete” limits use | | Payment-card numbers | Not stored by Fireworks, not impacted | Lowers direct card-fraud risk | | Evaluation environment variables incident one | Accessed in a limited number of customer accounts, could contain secrets | Requires rotation of any exposed keys and tokens | Billing data looks dull next to model weights, but it carries real risk. Addresses plus invoice history give a convincing script to a phisher posing as Fireworks’ finance team. Credit usage and balance reveal how heavily a company leans on the platform, which is competitive intelligence for anyone watching a rival’s AI spend. Teams that handle crypto or fintech data should note a parallel. Our reporting on the Chainalysis breach that touched all users across four data types https://shattered.io/chainalysis-breach-all-users-four-data-types-live-tokens-2026/ is another reminder that account-level details deserve the same care as headline assets, because they feed follow-on attacks. Incomplete Model Weights and Datasets: The Real Worry Fireworks wrote that, for certain customers, a subset of incomplete model weights and datasets was affected. Each word in that phrase narrows the claim. “Certain customers” means not all. “Subset” means not everything those customers stored. “Incomplete” means partial artifacts rather than finished, usable models. Still, partial weights are not harmless. A fine-tuned checkpoint that is part-way through transfer or storage can leak architecture details, tokenizer choices and training hyperparameters. A partial dataset can leak the shape of proprietary data, including its labels and sampling choices. Whether an attacker can reconstruct anything valuable depends on which pieces were taken, and Fireworks has not said. The quantity is the second unknown. Fireworks has not disclosed how many datasets or how much weight data were accessed, and no outlet has confirmed a figure. Reports of scale, discussed below, remain attributed to an unnamed source. Customers who trained on sensitive or regulated data should ask Fireworks directly whether their artifacts were among the subset. The AI-lab threat model has been shifting toward exactly this kind of target. Lisa Thiergart argued recently that spies are likely already inside AI labs, a claim we covered in our report on her warning, which named zero people https://shattered.io/lisa-thiergart-spies-at-ai-companies-security-level-5-zero-named-2026/ . The Fireworks case involves no such allegation, but it shows how weights and datasets have become prizes in their own right. Customers Named: Notion, Cursor, Harvey and 10,000 Others Bloomberg reported that Fireworks’ customers include Notion, Cursor and Harvey, among others. The Fireworks spokesperson’s statement to Bloomberg named Notion and Cursor as companies the firm is working with as it manages the incident. Bloomberg also reported that Fireworks’ website states it has over 10,000 customers. Those names tell readers how deep the platform runs into the software stack. Productivity software, AI coding tools and legal AI all route some model traffic through the same inference layer. When that layer is touched, the exposure does not stay inside one company’s perimeter. It reaches the vendors that rely on it. Naming a customer in an incident story does not mean that customer’s data was taken. Fireworks has not published a list of affected customers, and the spokesperson’s wording says the company is working with those firms to manage the incident, not that each lost weights or datasets. Readers should resist the shortcut of equating being named in coverage with having been breached. Developer-tool users also have a second-order worry. If an AI coding tool or workspace app sends customer prompts through Fireworks, its own users may want assurance about what that supplier held. Expect trust and security pages at downstream vendors to get edited in the coming weeks. Confirmed vs. Unconfirmed: Sorting the Claims Fast-moving incident coverage mixes verified facts with secondhand claims. The table sorts each item by status so that readers can see which statements rest on Fireworks’ own bulletin and which do not. | Claim | Status | Basis | |---|---|---| | Two separate incidents, October 6 and October 23-24 | Confirmed | Fireworks security bulletin | | Data categories affected metadata, billing, partial weights and datasets | Confirmed | Fireworks security bulletin | | Payment-card numbers not stored or impacted | Confirmed company statement | Fireworks security bulletin | | No further evidence of platform access as of October 25 | Confirmed company statement | Fireworks security bulletin | | Notion, Cursor, Harvey among customers | Reported | Bloomberg, Fireworks spokesperson | | Over 10,000 customers | Reported | Fireworks website, per Bloomberg | | “Tens of thousands of files” with customer data | Unconfirmed | Unnamed person familiar with the matter | | Exact number of affected customers | Undisclosed | Not published by Fireworks | | Quantity of weights and datasets accessed | Undisclosed | Not published by Fireworks | The “Tens of Thousands of Files” Report Bloomberg reported that a person familiar with the matter said the second incident involved tens of thousands of files containing customer data. Fireworks’ security bulletin does not confirm that figure. We treat it as a lead, not a fact, and we recommend readers do the same until Fireworks or a second named source supports it. Unverified numbers have a way of hardening into accepted truth after a few reposts. We saw a similar dynamic in a different case, where a crypto exchange called a huge leak claim likely a scam, a story we followed in our coverage of the 335.9M-line Binance claim https://shattered.io/binance-shinyhunters-335-9m-lines-claim-likely-scam-2026/ . Discipline about sourcing protects readers whichever way a claim eventually breaks. Why Two Incidents in Weeks Changes the Risk Math Fireworks says the two events behind the Fireworks AI hack are distinct. One involved misuse of internal credentials. The other flowed from a supplier’s compromise. Nothing in the public record links them, and we will not claim a link. Yet a security team reading the dates will ask whether one weakness fed the other, and Fireworks owes them an answer. Single incidents get graded on response. Repeated incidents get graded on posture. A buyer who forgave the first episode because Fireworks notified affected customers directly now has to ask whether the company’s access controls, secrets handling and supplier oversight were adequate before either event. That shift from response to posture is what turns a news cycle into a procurement review. Internal credentials and supplier access share one lesson. Long-lived secrets and broad standing access make every compromise bigger. Short-lived tokens, narrow scopes and strict separation between R&D and customer-facing systems shrink the blast radius. Fireworks’ October 25 statement suggests the separation held for the production platform, which is the strongest point in its favor. Customers should also weigh the time between the October 23 supplier event and the October 24 intrusion. That is a single day. If accurate as described, it implies the intruder moved quickly, which is a reason for suppliers and customers alike to tighten alerting on partner-originated incidents. Market Impact: Trust in Inference Platforms The Fireworks AI hack hits a private company, so there is no stock chart to read. The market impact shows up elsewhere, in renewals, security questionnaires and architecture choices. With over 10,000 customers reported, even a small share of buyers pausing new workloads would matter to a growth-stage vendor. Nvidia’s backing, noted in reports on the story, adds a reputational dimension. Investors and partners in the chip ecosystem lean on inference platforms to prove that open models can run safely at production scale. A pair of incidents tests that claim, particularly while the broader sector faces scrutiny over its security culture. Our report on PauseAI’s warning of an AI-driven cyber crisis within months https://shattered.io/pauseai-chief-ai-cyber-catastrophe-within-months-fournes-2026/ captures the wider mood. Short-term effects likely land on three fronts. Enterprise buyers will ask for incident reports and sub-processor lists. Procurement teams will add contract language on notification windows. Engineering teams will review how much sensitive material they park on any hosted platform, including datasets used for fine-tuning https://shattered.io/category/ai-machine-learning/ . None of that means customers will leave. Switching inference providers takes engineering effort, and many teams chose Fireworks for latency and open-model support, not for its security record. The likelier outcome is more demands, tougher terms and a few high-profile customers hedging across a second provider. Competitive Comparison: Managed, Self-Hosted and Hyperscaler Paths The incident revives an old argument over where inference should run. We do not have verified security data on any rival platform, so this comparison covers architecture, not track records. Each path trades convenience against control, and each has its own supplier risk. Managed inference platforms such as Fireworks give teams fast access to open models without managing GPUs. The cost is concentration. Many customers’ secrets, weights and metadata live in one operator’s environment, and that operator’s suppliers become everyone’s suppliers. The Fireworks case shows how a hosting provider’s incident can reach customers three steps removed. Self-hosted inference keeps weights and datasets inside the buyer’s own boundary. It shifts the burden of patching, monitoring and access control onto the buyer’s team, which is hard work for small companies. For teams weighing that trade on price as well as risk, our self-hosted LLM versus API cost comparison https://shattered.io/self-hosted-llm-vs-api-kimi-k3-1-pro-glm-5-3-deepseek-v4-1-mistral-large-4-2026/ sets out the numbers. Hyperscaler-hosted model services offer mature identity systems, private networking and audit tooling, usually at a price premium. They concentrate risk differently, since a single cloud account misconfiguration can expose a lot. Still, enterprises with strict compliance rules often prefer them because contracts, certifications and regional controls are well understood. The takeaway: no path removes risk. The question is whether a buyer can see, limit and recover from a supplier’s failure. Fireworks customers who kept secrets out of evaluation variables and used scoped, rotating credentials are in a better position than those who did not, whichever platform they use. Historical Context: Developer Platforms Keep Learning the Same Lesson Developer platforms have been through this cycle before. When a CI/CD or build vendor is compromised, customers learn to rotate every secret that vendor ever touched. Each time, the advice is the same: assume exposure, rotate fast, shorten credential lifetimes and watch logs for odd use of old keys. Supplier-driven incidents add a second lesson. Attackers have learned that going after a hosting or tooling provider can yield many downstream targets for the price of one. Recent breach coverage, such as the Gnosis Pay breach, where four data types tied cards to wallets https://shattered.io/gnosis-pay-breach-four-data-types-tie-cards-to-wallets-2026/ , shows how much account data sits in vendor systems. The industry keeps rediscovering that the weakest link may sit two contracts away. AI infrastructure adds new stakes to the old pattern. A leaked database password is a bounded problem. A leaked fine-tuned model or proprietary dataset is a permanent loss, because it cannot be rotated. That asymmetry will drive security spending at AI vendors, and it explains why incomplete weights drew so much attention in the Fireworks disclosure. What Customers Should Do This Week Teams do not need to wait for a full post-mortem to act. The steps below are general good practice, not claims about what Fireworks requires, and they apply whether or not a given account was named in a notice. - Rotate every API key, storage token and webhook secret that was ever passed to a Fireworks evaluation job, starting with anything reachable from outside your network. - Check Fireworks account emails for a notification and confirm any message came through a verified channel, since billing details make convincing phishing bait. - Ask your Fireworks contact in writing whether your weights or datasets fall within the subset, and request the date range and resource list. - Review billing and invoice emails for unexpected changes to payment or remittance details over the next several months. - Move evaluation secrets to short-lived, narrowly scoped credentials issued per job rather than stored as static variables. - Log which of your own downstream vendors rely on Fireworks and check whether they have posted updates. Teams in regulated industries should also bring legal and compliance staff in early. Contracts may set notification clocks, and a supplier’s incident can trigger duties for the customer. For broader reading on current incident patterns, see our security coverage hub https://shattered.io/security/ . Predictions: What Happens Next for Fireworks and Its Customers These are our own forecasts based on how comparable disclosures have unfolded. They are not reported facts. - A fuller post-incident report is likely. Pressure from large customers makes a more detailed bulletin probable, covering affected-customer counts, the workload’s purpose and the timeline of the supplier’s incident. Whether it names the cloud provider is less certain. - Security questionnaires will get longer. Expect inference buyers across the industry to ask vendors who hosts their R&D machines, how those machines connect to production and how quickly partner incidents are reported. - Static secrets in eval jobs will fade. Teams will move toward per-job credentials and secret managers, partly because the Fireworks warning about environment variables is so easy to understand. - Separation of R&D from production will become a selling point. Vendors will advertise architecture that keeps research hosts away from customer-facing systems, echoing Fireworks’ own October 25 statement. - Notification terms will tighten. Enterprise contracts will gain shorter notice windows for supplier-originated incidents, and some customers will demand the right to audit a vendor’s suppliers. Frequently Asked Questions What happened in the Fireworks AI hack? Fireworks reported two incidents. On October 6, 2026, it identified unauthorized use of internal credentials that exposed environment variables in evaluation jobs for a limited number of customer accounts. Then a third-party cloud provider hosting its R&D machines had an incident on October 23, and on October 24 an unauthorized third party reached development machines and ran an unauthorized workload. Was payment-card data stolen? Fireworks said payment-card numbers were not stored by Fireworks and were not impacted. Billing addresses, shipping addresses, invoice and payment history, account balance and credit usage were among the data it identified as affected. Which companies are affected? Bloomberg reported that Notion, Cursor and Harvey are among Fireworks’ customers, and a Fireworks spokesperson said the company is working with customers including Notion and Cursor. Fireworks has not published a list of affected customers, so appearing in coverage does not prove a company lost data. How many files or customers were hit? Fireworks has not disclosed the number of affected customers or files. Bloomberg reported a claim, attributed to an unnamed person familiar with the matter, that tens of thousands of files with customer data were involved. Fireworks’ bulletin does not confirm it. Were model weights stolen? Fireworks said that for certain customers, a subset of incomplete model weights and datasets was affected. It has not said how many weights or datasets were accessed, and it has not said how usable the partial artifacts are. Is the Fireworks platform still safe to use? As of October 25, 2026, Fireworks said it had not detected further evidence of successful unauthorized access to the customer-facing platform. That is a statement about evidence found so far. Cautious teams can continue using the service while rotating secrets and pressing the company for a fuller report. What should I do if I use Fireworks? Rotate any secret that touched an evaluation job, watch for phishing that uses billing details, and ask Fireworks in writing whether your weights or datasets were in the affected subset. Moving to short-lived, narrowly scoped credentials reduces the damage from any future incident.