Hackers Stole Thousands of Uber Drivers’ Licence Details in a Breach at AI Firm Fireworks

Uber has confirmed that hackers stole the personal information and driving-licence details of thousands of its drivers in the United States after breaking into one of its technology suppliers, the artificial intelligence infrastructure company Fireworks AI. The ride-hailing company began notifying affected drivers this week, more than a month after the attack, and the full number of victims is still unknown.

According to notices Uber filed with several state attorneys general, the attackers used stolen internal credentials belonging to Fireworks AI to reach Uber’s account with the provider, and from there to reach data Uber had stored with it. The breach was first reported by TechCrunch on Friday, and confirmed by Reuters the same day. An Uber spokesperson confirmed to both outlets that the provider at the centre of the incident was Fireworks AI, a company whose platform lets developers run, fine-tune and serve open AI models.

The disclosure is the most visible consequence so far of a wider incident at Fireworks AI that has also exposed customer data at the productivity company Notion and the coding company Cursor. In each case the pattern is the same: a compromise at a supplier reached through into its customers, and from there into their customers. What began as an attack on one AI infrastructure provider has become a case study in how far a single stolen credential can travel.

Uber said it had not identified any misuse of the stolen data so far, and it is offering affected drivers free credit monitoring and fraud assistance. But the company has not said how many drivers were affected nationwide, and the state filings published so far cover only a fraction of the country. That number is expected to rise as more notices are filed.

The numbers so far

According to breach notices reviewed by TechCrunch, the stolen data includes the driving licences of 2,567 people in Massachusetts, 3,430 people in South Carolina and 1,873 residents of Rhode Island, a combined total of 7,870. A filing in Illinois showed that some residents of that state also had their licence information stolen, but the number of people affected there was still pending. Uber also notified drivers who live in California, but did not say how many had their information compromised.

A separate notice filed with the attorney general of Iowa, and published in full on that office’s website, covers about 2,999 Iowa residents. Taken together with the three states TechCrunch counted, the confirmed total stands at at least 10,869 drivers, and that is a floor rather than a final figure. Uber has given no national total, and notices for other states, including California and Illinois, have yet to produce counts.

What was taken is unusually sensitive. According to Uber’s notice to Iowa, the personal information involved included images of drivers’ licences and extracted text data, including name, address, date of birth and licence number. A driving licence is not just an identity document. It is a bundle of the exact details needed to open accounts, apply for credit and impersonate its holder, and unlike a password it cannot be changed. That is why the notices stress credit monitoring, fraud alerts and security freezes.

The data was sitting in a cloud storage environment that Uber had created specifically to enable the provider’s work. According to the Iowa notice, that environment was subject to Uber’s cloud security management processes and overseen by Uber’s cloud security team, and alerting was enabled. But because the attackers used valid credentials, and data flows enabled by the compromise on the provider’s systems, no alerts were triggered. The notice adds that the provider’s compromised credentials did not provide access to other Uber systems, and that Uber’s investigation remains ongoing.

Uber is providing affected drivers with credit monitoring and fraud assistance at no charge through Cyberscout, a TransUnion company, and recipients have 90 days from the date of their letter to enrol. The company’s notice to drivers says it has not identified any misuse of the data to date, while recommending that drivers review their account statements, check their credit reports and consider placing a fraud alert or a security freeze with the credit bureaus.

How the attack reached Uber

The timeline, as set out in Uber’s own notices and in Fireworks AI’s security bulletins, is a slow one. On 6 October, according to Fireworks AI’s first bulletin, the company identified a security incident involving the unauthorised use of its internal credentials. An unauthorised third party had accessed environment variables used in evaluation jobs in a limited number of customer accounts. Fireworks began notifying affected customers on 7 October and published its bulletin on 9 October.

According to Uber’s notice to the Iowa attorney general, the provider told Uber on 9 October that an unauthorised third party had compromised the provider’s internal credentials and used them to access Uber’s account with the provider. Uber says it immediately severed its data connections with the provider and launched an investigation. On 13 October, that investigation determined that the unauthorised party had used the compromised credentials on 7 October to access Uber data containing personal information connected to the provider.

The letters to drivers are dated 10 November, a month after the first alert and almost five weeks after Uber confirmed the access. That gap is the distance between an incident and a notification, and it is the part of the story that will draw the most scrutiny from regulators. Uber’s notice does not name the provider. TechCrunch identified it as Fireworks AI, and an Uber spokesperson confirmed the identification to TechCrunch and to Gizmodo, saying the notices to drivers related to “a security incident impacting one of our third-party vendors, Fireworks.ai, which had access to some Uber data”.

What Uber has not explained is what it used Fireworks AI for, or why drivers’ licence images were within the supplier’s reach at all. That question matters, because the answer determines whether the data was there by design or by accident. A licence image held by an inference provider is not an obvious part of running a ride-hailing service, and Uber’s notices offer no explanation. Fireworks AI, for its part, confirmed to TechCrunch that it had identified a security issue involving unauthorised access to some of its systems that affected customer data, but did not answer the publication’s questions about the incident.

Fireworks AI: the company at the centre

Fireworks AI is not a household name, but it sits at a busy junction of the AI economy. The company was founded in 2022 by Lin Qiao, who previously led the PyTorch team at Meta, together with a group of co-founders drawn largely from Meta and Google. It is based in Redwood City, California, and sells inference capacity: instead of building their own infrastructure to run AI models, companies call Fireworks’ platform through an application programming interface and pay for the computing they use.

The business has grown at an extraordinary pace. In its own announcement of a Series C funding round in October 2025, Fireworks said it had raised 250 million dollars at a 4 billion dollar valuation, and that it processed more than 10 trillion tokens a day for more than 10,000 customers. Funding databases report that the company raised a further 1.505 billion dollars in July 2026 at a 17.5 billion dollar valuation, with annualised revenue passing 1 billion dollars and daily token volumes above 40 trillion. Its publicly named customers include Uber, Shopify, DoorDash, Upwork, Samsung, Genspark and the legal AI company Harvey, as well as the coding tool Cursor and the productivity company Notion.

That customer list is the reason this breach matters beyond Uber. When a platform serves thousands of companies, a single compromise becomes a supply-chain incident, and the damage is measured not in one company’s records but in all of them. Bloomberg Law reported on 9 November that a Fireworks spokesperson said the company was “actively working with our customers to manage the incident, including Notion, Cursor and others”. The Information, as reported by Benzinga on the same day, said Fireworks had told some large customers, including Harvey, of “a recent, more serious hack”, and that some customers who spend millions of dollars a year on its services were considering switching to other providers. That switching claim rests on anonymous sources and has not been confirmed by any of the companies named.

A second way in

Fireworks AI’s account of the incident changed materially between its first bulletin and its update. The first bulletin, published on 9 October, said that at the time of publication only Fireworks-stored secrets, such as those used in evaluation jobs, were known to have been accessed, and that the company had found no evidence of access to customer models, datasets, training data, personal information or inference traffic.

The update published on 9 November tells a wider story. According to Fireworks, a third-party cloud provider that hosted its research and development machines experienced a security incident on 23 October. On 24 October, the unauthorised third party used that incident to reach Fireworks’ development machines and then run an unauthorised workload that led to additional customer data impact. Fireworks says it detected the activity the same day, took immediate remediation measures and closed known critical vulnerabilities, and that as of 25 October it had not detected further evidence of successful unauthorised access on the platform customers use.

The update also widened the list of what was reached. The affected internal application provided access to resource metadata, such as Fireworks resource identifiers, display names, descriptions and creation times; to billing information, including billing and shipping addresses, invoice and payment history, account balances and credit usage; and, for a limited set of accounts, to secrets, datasets and incomplete model weights. Fireworks says it does not store payment card numbers and that those were not impacted.

Fireworks says it has not detected any impact to Inference, the Training SDK or Nexus, which it describes as zero data retention by default. But that finding is qualified in the bulletin itself: “These findings are based on our investigation to date. Our investigation is ongoing and may reveal additional information.” The same qualification applied to the October bulletin, which said no models or datasets had been touched. A month later, the update said otherwise. That is not an accusation of bad faith. It is a reminder that a company’s statement about what was not affected is only as reliable as the investigation behind it, and this investigation is still running.

As part of its response, Fireworks says it revoked and replaced credentials and service accounts, removed unnecessary elevated privileges, restricted network pathways, isolated affected systems and tightened access to data storage and analytics. It has disabled self-serve dataset uploads and downloads used by batch inference and dataset-based training while the investigation continues. It says it notified law enforcement and brought in Palo Alto Networks’ Unit 42 to conduct forensic analysis.

Notion: the chats that were supposed to vanish

The second confirmed victim is Notion, the productivity company, and its story is in some ways the more troubling of the two. According to Notion’s own security advisory, the Fireworks incident affected fewer than 1 per cent of Notion workspaces. The data taken included Notion AI chat transcripts used for the company’s Insights feature, a tool that analyses how a workspace uses AI. For the vast majority of impacted workspaces, Notion says, the transcripts were unattributable: there was no information tying the chat back to a workspace, a user or a company, and they did not contain tool call results such as Notion page content.

The timeline Notion published shows how the picture changed over a week. On the evening of 2 November, Fireworks notified Notion that a small set of data had been accessed by malicious actors; on investigation, that dataset included Notion AI synthetic testing data, and no Notion AI customer data was involved. By the morning of 3 November, Notion had disconnected its systems from Fireworks, deleted all its data in the Fireworks system and stopped all communication between the systems. On 4 November it deleted all its data in the Fireworks system. On 6 November, Fireworks told Notion that malicious actors may have accessed potential customer data, and Notion began another internal investigation. On 8 November, Fireworks confirmed the final impacted dataset, and Notion found that it included the Insights chat transcripts. Notion reached out to impacted customers on 9 November, and published its security advisory on 10 November, updating it on 12 November.

Notion’s response has been concrete. It has disabled the Insights feature and says it is no longer serving open-weight models through Fireworks. On 11 November it revoked Notion API keys it found inside the affected user messages, and on 12 November it reported third-party API keys found in the same transcripts to the vendors that issued them. It advises affected customers to treat the exposed data as if it were exposed, and to rotate any password, API key or other credential they pasted into Notion AI during the period in question. It says no other Notion features were affected, and it stresses that “this was not a breach of our systems”.

What makes the Notion case different is a broken promise. According to Notion, Fireworks had given “a contractual commitment to zero data retention for our use of its platform”. Notion says it learned during its investigation that “data was retained from the Fireworks endpoints that we used”. In other words, transcripts that were supposed to exist only in transit, and then disappear, were stored at the vendor, and it was that stored copy that the attackers reached. A zero-retention commitment is only as strong as the systems that enforce it, and here the systems did not.

Cursor: one key opened three companies

The third confirmed victim, Cursor, published the fullest account of the three, and it shows how far a single exposed credential can travel. In an incident update published on 13 November, Cursor said its October security incident began at Fireworks. “An attacker obtained an access key we had issued to Fireworks,” the company wrote. “The key was exposed by Fireworks, and the attacker used it to copy data from a read-only storage bucket we used to share data with them.”

That bucket contained limited coding agent traces, mostly from 2025, from sessions not in Privacy Mode, which Cursor said it was permitted to use for model training. A small number of those traces contained credentials that had not been redacted. Cursor says fewer than 0.05 per cent of users had coding agent traces exposed, and fewer than 0.01 per cent of customers had API credentials exposed. Starting with those credentials, the attacker reached select software-as-a-service tools used by Cursor, and from those tools accessed archived non-production source code repositories, limited customer support data and email conversations, product usage metrics and contact details, summaries of some coding agent conversations, and some credentials users had sent to the Cursor support team.

Then the attacker did something more aggressive. On 29 October, using a stolen credential from the exposed internal data, the attacker placed malicious, unauthorised copies of Anthropic’s Claude Code extension, versions 2.1.312 and 2.1.313, directly on the cache used to serve Cursor’s Visual Studio Code extension marketplace. Anthropic did not publish those copies, Cursor says, and the marketplace source, Open VSX, never had the malware. At most 5,000 users who requested the specific cached versions on 29 October potentially received the malicious build. It was available for approximately 11 hours before Cursor removed it, took the extension marketplace offline and worked with the cloud provider hosting the attacker’s server to take that down.

Cursor says it believes the incident is contained, that the last attacker activity it has seen was on 1 November and that it was blocked. It has moved all inference traffic off Fireworks, deactivated the key it had issued to the vendor and cut off Fireworks’ access to all datasets it had shared with it. It has rotated every exposed credential it found, and as a precaution rotated all credentials in use across its internal systems, even where it had no evidence of exposure. It says Privacy Mode prompts and code were not affected, nor were its production systems, its customers’ code repositories, the Cursor app and its official updates, or any other extension in its marketplace. No release signing keys were exposed.

One point of attribution matters here. That the key was “exposed by Fireworks” is Cursor’s account. Fireworks’ own security bulletins, last updated on 9 November, do not mention Cursor at all. The two companies’ accounts are not in conflict, but they are not the same document, and the chain from a Fireworks exposure to a Cursor marketplace compromise is, for now, established by Cursor’s word alone.

LLMJacking: the motive was the models, not the data

Fireworks links the attack to a financially motivated cybercriminal group whose aim, in its words, is selling tokens from unauthorised access to large language models to illicit routing gateways, a practice known as LLMJacking. The company points to a report published on 2 November by Google’s Threat Intelligence Group and Mandiant, “The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources”, which describes the practice in detail.

According to Google’s report, attackers hijack an organisation’s access to large language models, burn through its cloud budget, and resell that access cheaply to others. Unlike cryptojacking, which gradually consumes resources, Google says LLMJacking “can generate large spikes in fraudulent cloud charges in a matter of hours”. In incidents Mandiant investigated during 2026, fraudulent charges exceeded 100,000 dollars in a single day, and cumulative charges at some organisations reached 1 million dollars before access was cut off. In one case, attackers made more than 500,000 API calls in under eight hours through a resale gateway. The report describes “LLM Mixers”, illicit routing gateways that pool stolen keys, meter them and resell access to underground subscribers, and it names a cluster tracked as UNC6993 that compromised cloud instances through misconfigured service account keys.

The motive reframes the whole incident. If the attackers’ goal was to steal and resell access to AI models, then the drivers’ licences, the Notion chat transcripts and the Cursor agent traces may not have been the target at all. They may have been collateral: data that happened to be sitting in the systems the attackers reached on their way to the models. That does not make the exposure less serious. A licence image stolen as a by-product is still a licence image in criminal hands. But it does explain why the breach looks so scattered, touching billing records, datasets, model weights, chat transcripts and licence images at once. The attackers were not shopping for any one of those things. They were shopping for computing power, and they took whatever else was in the room.

Uber has been here before

For Uber, this is familiar ground, and the company’s history is the reason the details of its response will be examined closely. In November 2016, hackers used stolen credentials to reach a private source code repository, obtain a private access key, and copy data belonging to 57 million users and drivers, including 600,000 drivers’ licence numbers. The company paid the hackers 100,000 dollars, concealed the breach from the Federal Trade Commission for about a year, and disclosed it only in November 2017 under new leadership. In 2018 it paid 148 million dollars to settle with the attorneys general of all 50 states and the District of Columbia, and in 2022 it entered a non-prosecution agreement with the Department of Justice over the cover-up.

The company was breached again in 2022, when the extortion group Lapsus$ gained access to its systems, and TechCrunch notes that this week’s disclosure is Uber’s second known data breach this year, after a security incident at its Uber Freight truck shipping unit for which an extortion gang took credit for stealing data.

The contrast with 2016 is real and it matters. This time Uber filed notices with state attorneys general within a month of confirming the access, offered credit monitoring without being forced to, and there is no evidence so far of any attempt to conceal the incident. But the similarity is also real, and it is the more important of the two. In 2016 the attackers got in with stolen credentials and a private key. In 2026 the attackers got in with stolen credentials belonging to a supplier. The entry point moved one step outwards, to a vendor, but the mechanism is the same: a credential that opened a door it should not have opened, and a system that treated a valid credential as a trusted one.

Analysis: Why It Matters

The victim was three companies away from the break-in

Trace the chain backwards from an Uber driver in Iowa whose licence image was stolen. The image sat in a cloud storage environment Uber built for a supplier. The supplier was Fireworks AI. Fireworks was reached, in the second of two intrusion paths, through a third-party cloud provider that hosted its research and development machines. The driver never dealt with Fireworks, and certainly never dealt with Fireworks’ cloud provider, yet that provider’s security is now the driver’s problem. This is the modern supply chain in its least forgiving form: a company’s data is only as safe as the weakest security among its vendors, its vendors’ vendors, and the vendors beyond them. No contract a driver signed, and no setting a driver chose, could have protected against it. The only defence was diligence further up the chain, by companies the driver will never hear of.

“Zero data retention” was a promise, not a fact

The Notion episode is the most instructive part of this incident, because it exposes the gap between a contractual commitment and an operational reality. Notion says Fireworks had contractually committed to zero data retention for its use of the platform. Notion’s own advisory says the data was retained anyway, from the endpoints Notion used. Nothing in Notion’s systems failed. The failure was that a promise made in a contract was not enforced by the systems that were supposed to implement it, and nobody discovered the discrepancy until attackers found the stored data first. Every company that routes customer data through an AI provider should read that paragraph twice. A vendor’s assurance about retention is a claim about its architecture, and architecture can only be verified by audit, by testing, and by asking uncomfortable questions before a breach, not after one. The lesson is not that zero retention is impossible. It is that zero retention is a property you have to prove, continuously, and that a line in a contract is not proof.

The thieves wanted the models; the licences were collateral

It is tempting to read this breach as a data theft, because data is what was stolen. But the motive Fireworks and Google describe is different, and the difference changes what companies should defend. LLMJacking is a theft of computing power, not of information. The attackers wanted access to expensive models, and they wanted it at someone else’s expense, so they could resell it. The licence images, the chat transcripts, the billing records and the model weights were, on this account, incidental: things that happened to be stored in the systems the attackers walked through on their way to the inference capacity. That is a worse problem, not a better one, because it means the attack surface is not limited to the data a company cares about. It includes every credential, every bucket and every evaluation job that touches a model, including the ones nobody thought were sensitive. A key issued to a vendor for training purposes became the route into a marketplace. A chat transcript stored for an analytics feature became an exposure. The economics of AI have made model access itself a target, and every company that buys inference is now holding an asset thieves want to steal and resell.

One leaked key became a software supply-chain attack

The Cursor chain deserves attention on its own, because it is the part of this incident that came closest to harming people who had nothing to do with any of the companies involved. A key issued to Fireworks was exposed. The key opened a read-only bucket. The bucket held agent traces. The traces held unredacted credentials. The credentials opened software-as-a-service tools. The tools led to a marketplace cache. The cache served a tampered copy of a popular coding extension to as many as 5,000 developers. Each step was small, and each was the kind of thing that looks routine in isolation. Together they form a textbook supply-chain attack, delivered not through a compromised package or a malicious update, but through a credential that was issued for a legitimate purpose and then left exposed at a vendor. The defence that would have stopped it is also small: redact credentials from traces before they are stored, scope vendor keys so they cannot reach production-adjacent systems, and verify the integrity of what a marketplace serves. None of those are exotic. All of them were missing at the moment that mattered.

Uber’s disclosure has improved; the credential problem has not

It is fair to credit Uber for the difference between 2016 and 2026. A company that once paid hackers 100,000 dollars and hid a breach for a year filed notices with state attorneys general within weeks of confirming this one, and offered credit monitoring to the people affected. That is a real change, and it is the change regulators and settlements are designed to produce. But it is also a change that treats the symptom rather than the cause. In 2016, stolen credentials opened Uber’s own systems. In 2026, stolen credentials belonging to a supplier opened Uber’s data. The credential is still the weak point, and the lesson of both breaches is the same: a valid credential is treated as a trusted identity, and a trusted identity is rarely questioned. Until credentials are scoped so tightly that a stolen one can do almost nothing, and monitored so closely that unusual use triggers an alert even when the credential is valid, the next breach will follow the same pattern, through the next vendor, and the next notification will go out a month later.

What to Watch Next

1. The nationwide driver total. State filings so far cover 7,870 drivers in three states plus about 2,999 in Iowa. Counts for California and Illinois are still outstanding, and the total is expected to rise as more notices are filed.
2. Whether the licence data is misused. Uber says it has identified no misuse so far. Driving licence images, with name, address, date of birth and licence number, are prime material for identity theft, and the first reports of fraud will be the real measure of the damage.
3. What Fireworks finds next. The company’s investigation is ongoing, and its November update already widened the scope once. Further categories of affected data, or further named customers, would change the scale of the incident again.
4. Whether regulators act. State attorneys general now hold Uber’s notices, and the Federal Trade Commission has a history with this company. Any inquiry, and any question about why a month passed between confirmation and notification, will be worth following.
5. Whether Fireworks keeps its customers. Reports that some large customers are considering leaving the platform rest on anonymous sources, but Cursor has already moved all inference off Fireworks and Notion has stopped serving open-weight models through it. The next customer departure, if there is one, will be a signal.
6. What happens to Notion’s Insights feature. The feature is disabled while Notion investigates. Whether it returns, and under what retention terms, will show whether the zero-retention failure changes how the feature is built.
7. The LLMJacking crackdown. Google’s report describes a resale market for stolen model access. Watch for spend caps, key scoping and anomaly detection becoming standard at inference providers, and for law enforcement action against the illicit routing gateways that make the trade profitable.

Sources

• Fireworks AI, “Update on October 2026 security incident” (security bulletin, updated 9 November 2026)
• Uber Technologies, “Notice of Security Incident” (filed with the California Attorney General, 10 November 2026)
• TechCrunch, “Uber confirms hackers stole thousands of drivers’ license information in data breach” (13 November 2026)
• Reuters, “Uber says US drivers’ license data stolen in data breach” (13 November 2026)
• Notion, “Fireworks AI incident” (security advisory, updated 12 November 2026)
• Cursor, “An update on our recent security incident” (13 November 2026)
• Google Threat Intelligence Group and Mandiant, “The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources” (2 November 2026)