Uber Driver Data Breach: Inside the Fireworks AI Hack

Uber has spent this week telling thousands of drivers that their personal information and driver’s license numbers were stolen last month. The paperwork behind the notices reads differently from most breach disclosures. In filings with several U.S. attorneys general, including California, Uber said a technology provider told it on October 9 that intruders had broken in, stolen internal credentials, and used them to reach Uber’s data. TechCrunch identified the provider as Fireworks AI, the inference platform developers use to run open-weight models without managing GPU infrastructure themselves.

The notices reviewed by TechCrunch count 2,567 affected people in Massachusetts, 3,430 in South Carolina, and 1,873 in Rhode Island. An Illinois filing is still waiting on a headcount, and California’s notifications carry no number at all. That adds up to at least 7,870 drivers across three states, and the tally should grow as more filings land.

Fireworks attributes the intrusion to a financially motivated criminal group that sells stolen access to large language models, and no known group has publicly claimed the theft. The driver’s licenses were collateral. They sat in storage belonging to a vendor whose credentials and compute were what the attackers wanted, so the exposure says less about Uber’s own perimeter than about what happens when regulated personal data flows into AI infrastructure that criminals have learned to monetize. The forensic record is unusually detailed, spread across two Fireworks security bulletins, state filings, and threat research from Google and Mandiant. It deserves a technical reading.

Fireworks AI breach timeline: two intrusions 18 days apart

Fireworks’ first bulletin describes a credential compromise. At 9:00 a.m. PDT on October 6, the company detected unauthorized use of internal Fireworks credentials and began containment the same day. A third party had accessed environment variables used in evaluation jobs across a limited number of customer accounts. Customer notifications began at 7:00 a.m. on October 7. Employee API keys were rotated on the afternoon of October 9, identified affected customers were notified that evening, and the bulletin went public at 10:00 p.m. On October 10, after a completed credential review, Fireworks revoked additional user API keys and rotated service-account tokens, with further review continuing. Some of the revoked keys had been created by the attacker.

Environment variables are a soft target for reasons any engineer who has shipped a containerized pipeline will recognize. Secrets injected at job launch (third-party API keys, storage tokens, webhook credentials) live in the process environment, get inherited by child processes, and can be read by any code running inside the job, including through trivial interfaces such as /proc/self/environ on Linux. Evaluation jobs make this worse by design. They run candidate models against test data and call out to external services, so they tend to carry more credentials than a minimal inference worker. Fireworks said it believed API keys and tokens stored as secrets were captured in the affected accounts. Its customer guidance includes the sentence every security team should memorize: removing a stored secret from the Fireworks dashboard does not invalidate the underlying credential, because third-party credentials must be rotated with the providers that issued them. A copy that has already been exfiltrated keeps working until the issuer kills it.

The second intrusion had a different architecture. According to Fireworks’ updated bulletin, a third-party cloud provider hosting Fireworks research and development machines suffered its own security incident on October 23. On October 24, the unauthorized party used that foothold to reach Fireworks development machines and run an unauthorized workload, which caused additional customer data impact. Fireworks detected the activity the same day, ran its incident response process, and closed known critical vulnerabilities. As of October 25 it had found no further evidence of successful unauthorized access on the customer-facing platform. The company notified law enforcement and brought in Palo Alto Networks Unit 42 for forensic analysis. The sequence implies the attackers never had to beat Fireworks’ front door twice. They compromised a hosting provider one level down the stack and moved laterally into an R&D environment that could reach an internal application holding customer data.

Uber’s own timeline, summarized by the law firm Strauss Borrelli from its South Carolina filing, runs alongside this one. Uber was alerted on October 9, cut its data connections with the provider, opened an investigation, and determined on October 13 that the unauthorized party had accessed Uber data connected to that provider. The formal notice date was November 10.

The public record doesn’t say which of the two intrusions exposed the driver records, or which Fireworks workflow held them. Neither company has said. Uber deferred questions to Fireworks, and a Fireworks spokesperson confirmed unauthorized access to some systems affecting customer data but did not answer TechCrunch’s specific questions. Anyone modeling their own exposure should treat that gap as an open question and resist filling it with speculation.

What data was exposed in the Fireworks AI breach

The updated bulletin lists what the compromised internal application exposed. First came resource metadata: Fireworks resource identifiers, display names, descriptions, and creation times. Billing information followed: billing and shipping addresses, invoice and payment history, account balance, and credit usage. Payment card numbers were unaffected because Fireworks does not store them. For a limited set of accounts, the attacker also reached secrets, datasets, and a subset of incomplete model weights.

Partial weights from unfinished training or fine-tuning runs aren’t a deployable production model. Datasets are another matter. A dataset is whatever the customer uploaded, and in a document-processing or classification pipeline that can mean raw records with names and identity numbers in plaintext. The sensitivity of this breach sits mostly in the datasets.

Fireworks was just as specific about what it did not find. It detected no impact to Inference, the Training SDK, or Nexus, all of which are zero-data-retention by default. The Training SDK remains available with no training data stored at rest, and Fireworks Lab-based training runs in an isolated environment with additional network and storage protection. As a containment measure, the company disabled self-serve dataset uploads and downloads used by Batch Inference and dataset-based training while the investigation continues. The hardening work with Unit 42 read like a textbook credential-intrusion response: revoking and replacing credentials and service accounts, stripping unnecessary elevated privileges, tightening controls to prevent new unauthorized credentials from being created, isolating affected systems and restricting unauthorized network pathways, and re-reviewing access to data storage and analytics systems to block public or unauthorized reads. Every remediation step targets identity and network reach, because identity and network reach were the attack.

Fireworks AI zero data retention: marketing claim vs. enforced configuration

The most instructive technical detail here is the distance between “zero data retention” as a product claim and zero data retention as an enforced setting. Fireworks’ documentation is honest about the boundary. For open-model inference, prompt and generation data exist only in volatile memory for the duration of the request and are never written to persistent storage without explicit opt-in. If prompt caching is active, some prompt data and associated KV caches can persist in volatile memory for several minutes. The platform still logs metadata such as token counts to operate and bill the service. The same page says plainly that zero data retention does not apply to the Batch API, which requires dataset storage, or to the Responses API when requests carry store=True, which is the default. Stored responses keep full conversation content, including prompts, model outputs, and tool calls, for up to 30 days, held in a cache that often evicts entries within about an hour.

There is a stronger control. Fireworks offers an account-wide Zero Data Retention policy, available on Enterprise accounts, that rejects every request or job that would persist or log customer content: batch inference jobs, dataset uploads, supervised fine-tuning, DPO and reinforcement fine-tuning, evaluators and evaluation jobs, custom model uploads, quantization jobs, and Responses API calls with store: true or background: true. Only account admins can change it, and it applies to every user and API key on the account. The documentation says the policy is off by default, and that default is the one security architects should audit. Enabling it deletes nothing already stored. Admins can enforce it in the console, with firectl policy zdr set --default on, or through a PATCH to the account’s policySettings endpoint with updateMask=zero_data_retention. An absent zeroDataRetention block in the response means the policy is off.

Read the two documents together and the lesson reaches past one vendor. A platform can truthfully advertise stateless inference while its batch queues, uploaded datasets, stored responses, and training artifacts sit in persistent object storage, protected by whatever identity and network controls the vendor runs. The synchronous request path was never where this breach lived. Enterprise teams that assumed the marketing default covered their asynchronous pipelines were relying on a guarantee that was never made, and the enforceable version is a flag most accounts have never touched.

Notion AI breach: chat transcripts and API keys pasted into prompts

Notion is the other confirmed casualty, and its disclosure adds a detail that should worry any company deploying internal AI features. Notion said it disconnected its systems from Fireworks on November 3, deleted the data stored there, and stopped all connectivity between the two companies. Fireworks alerted Notion on November 6 that malicious actors may have accessed customer data and confirmed the theft on November 8. The stolen material was chat transcripts from Notion AI’s Insights feature, covering any input to or output from the model that was written to the chat. Notion said much of it was unattributable, meaning even the company couldn’t tell which customer a transcript belonged to. The affected population was around one percent of its customers, which SecurityWeek framed as less than one percent of Notion workspaces.

The follow-up updates in Notion’s advisory are the novel part. On November 11, Notion revoked exposed Notion API keys that its investigation found inside affected user messages. On November 12 it reported exposed third-party API keys, also found in user messages, to the vendors that issued them. Users had pasted live credentials into AI chats, those chats were persisted for a product feature, and a vendor breach turned the transcripts into a credential dump that needs issuer-by-issuer rotation. It is the same failure as the evaluation-job environment variables, one layer up the stack. Secrets pile up wherever text piles up, and retention decisions made for product convenience become security liabilities when someone else’s development machine gets popped.

LLMjacking explained: the criminal market for stolen LLM access

Sysdig’s threat research team coined the term LLMjacking in May 2024 after finding attackers using stolen cloud credentials to run hosted models, particularly Anthropic’s Claude via AWS Bedrock, at the victim’s expense. Google Threat Intelligence Group and Mandiant published the industrialized version on November 2, 2026: multiple 2026 incident-response engagements across North America, South America, and Asia Pacific, hitting financial services, retail, technology, and transportation. Fraudulent consumption charges exceeded $100,000 in a single day, and cumulative bills reached $1 million at some organizations before access was revoked. Unlike cryptojacking, which sips resources quietly, hijacked inference burns money in hours.

GTIG’s report describes a division of labor that looks like a legitimate industry. Some clusters establish initial access. Others run monetization infrastructure the researchers call LLM Mixers, illicit routing gateways that proxy, aggregate, and resell unauthorized model access to paying subscribers. In one investigation, two distinct clusters coordinated to compromise and then monetize a single enterprise’s LLM infrastructure. The economics explain the specialization. The Jet Night service, at jet-night[.]com, sold an unlimited-token plan with claimed frontier-model access for roughly $60 a month, against a legitimate market rate of $100 to $250 for comparable consumer access, a price point GTIG believes only works with stolen keys. One actor behind Jet Night executed more than 500,000 LLM API calls in under eight hours and passed nearly a million dollars in token costs to the victim organization. The service’s public Telegram channel advertised outages that likely lined up with victims discovering the theft and revoking keys.

LLMjacking tradecraft: how attackers steal and validate API keys

The tradecraft is documented down to the request parameters. The dominant initial-access vector across Mandiant’s cases was exposed or stolen cloud identity material: IAM credentials, service-account keys, GitHub personal access tokens, and active session tokens. One group harvested corporate LLM API keys from public GitHub repositories and validated them with automated sweeps using single-token requests (max_tokens=1), specifically to stay under EDR and SIEM volume-anomaly thresholds. Another, tracked as UNC6993, ran a session-hijacking page that tricked users into pasting raw JSON payloads containing active access tokens, which bypassed password and MFA controls entirely.

After compromise, actors cloned repositories to grep for hardcoded secrets, queried cloud data-warehouse metadata tables for database credentials, abused token-creation privileges to mint temporary credentials for high-privilege service accounts, injected SSH keys into compute instance metadata, and created backdoor service accounts disguised as internal billing-optimization utilities.

LiteLLM CVE-2026-40217 and the resale gateways

The monetization layer has its own vulnerabilities. GTIG documented a follow-on cluster exploiting CVE-2026-40217, a user-ID rebind flaw in the /key/regenerate endpoint of the popular LiteLLM gateway, to elevate ordinary virtual keys into full PROXY_ADMIN master credentials. The actors subscribed victim accounts to pay-as-you-go agreements on premium models and ran a “burn and rotate” strategy, continuously creating and deleting short-lived service accounts to dodge rate limits while watching the victim’s billing interface. They also requested GPU quota increases through provider APIs and pooled stolen keys behind open-source gateways such as new-api and gcli2api, or custom relays hosted on lookalike domains feeding resale storefronts like newapi[.]pro.

Coverage of this breach keeps blurring two meanings of “token.” The tokens being stolen are authentication tokens. The tokens being sold are units of model inference. The crime converts the first into the second, and the victim’s invoice is the exchange rate.

Is the Fireworks breach linked to a known threat group?

Fireworks says it believes the attackers are financially motivated and focused on selling tokens from breached LLM access. Its first-stage remediation included revoking keys the actor had created, which matches the key-minting behavior GTIG describes across its cases. GTIG’s report doesn’t name Fireworks, though, and no group has claimed credit for this theft. The overlap amounts to a pattern match and falls short of attribution. The defensible reading is that Fireworks was hit by operators working a playbook that is now well documented across the industry.

Uber’s second 2026 breach: Uber Freight and the fourth-party risk problem

This is Uber’s second known breach of the year, and the first took a different route to the same structural weakness. On August 6, the extortion group Helix listed Uber Freight on its data-leak site, claiming nearly one million files taken from mailboxes, OneDrive accounts, and accounts-receivable repositories. Uber Freight confirmed the following week that someone had accessed part of its systems without permission. It said the incident was identified, contained, and remediated with federal law enforcement engaged, reported no impact on business operations, and declined to verify Helix’s claims about the material.

GTIG tracks Helix as one of several extortion brands, alongside Falcon, Pink, and Redact, that grew out of the BlackFile operation it clusters as UNC6671. Shared phishing templates and root domains such as passkeyhelpdesk[.]com link them, and those domains targeted victims who were later extorted under different brands. The group’s callers phone employees on personal mobile numbers, sometimes spoofing the real helpdesk line, invoke urgent FIDO2 passkey enrollment, and steer victims to adversary-in-the-middle panels that capture credentials and MFA session tokens. Scripted exfiltration against Microsoft 365 and Okta follows. GTIG counted 141.65 BTC, about $10.69 million, flowing into 18 BlackFile wallets between January 7 and May 12, 2026, with final payments averaging around $750,000 after negotiations shaved 50 to 75 percent off initial demands. One caveat applies: Google does not identify Uber Freight as a confirmed UNC6671 victim, and Uber Freight has not said how the intruder got in.

Set the two incidents side by side and what they share is topology. In August, identity infrastructure and human trust were the way into a logistics unit’s cloud storage. In October, a hosting provider beneath an AI vendor was the way into that vendor’s development environment, which held Uber’s data. The October chain is the more uncomfortable one because it is a fourth-party failure. Uber’s exposure ran through Fireworks and then through a cloud provider Uber has never named, likely never assessed, and possibly never knew existed. A vendor questionnaire that asks where data is stored and whether it is encrypted can’t see that path. The question that would surface it is narrower and rarer: which of your vendors’ development systems can read our data, and whose infrastructure do those systems run on?

How to prevent LLM API key theft and AI vendor breaches

The preventive agenda follows from the forensic record with little guesswork, and most of it is identity engineering.

Fix the credential lifecycle inside ML jobs

Fireworks’ own guidance tells customers to rotate exposed third-party credentials at the issuing provider and to review those providers’ access logs for unauthorized reads even when nothing looks suspicious, since deleting the vendor-side copy accomplishes nothing. The durable fix is to stop shipping long-lived secrets into evaluation and training runtimes at all. That means short-lived, audience-scoped federated credentials via OIDC, service accounts limited to a single storage prefix or model endpoint, and centralized secrets management with automated rotation. It matches the credential-hygiene and least-privilege posture in GTIG’s mitigation guidance, which includes segmenting API keys by model, environment, and usage limit so a stolen utility key can’t invoke frontier models.

Verify data retention instead of assuming it

Treat retention as a configuration to verify. If a pipeline genuinely needs stateless handling, enforce the account-wide ZDR policy and confirm it programmatically, since an absent zeroDataRetention block in the policy settings response means the protection is off. Turning it on leaves previously stored datasets and responses in place until you delete them.

Where batch processing is operationally necessary, and for document-heavy workflows it usually is, minimize the payload before it crosses the API boundary. Tokenize or redact license numbers and other regulated identifiers inside your own environment, so the vendor’s persistent storage holds references and no identity documents. Notion’s incident adds a control most DLP programs still miss: scanning user-authored prompts for pasted credentials, because a transcript store has now been shown to be a secret store.

Detect leaked credentials before the invoice arrives

Detection engineering should assume some credentials will leak anyway. GTIG’s guidance is specific. Alert on unauthorized enablement of LLM services, since in several Mandiant cases the services weren’t even switched on until the attacker enabled them. Watch CloudTrail for Bedrock InvokeModel and Converse spikes, model-listing reconnaissance, and any attempt to disable invocation logging. Hunt for max_tokens=1 validation pings and anomalous key-creation events. GCP’s relevant Data Access logs are disabled by default and must be explicitly turned on before any of this is visible. Per-model quotas, spending caps, and gateway patching close the loop, with LiteLLM-class routing middleware inside the vulnerability-management scope. Treat the vendor, and the vendor’s vendor, as part of your own attack surface. This breach shows they are.

What Uber is offering affected drivers

Uber said in its notice that it had not identified misuse of the stolen information as of the filing date. It is offering affected drivers complimentary credit monitoring and fraud assistance through Cyberscout, a TransUnion company, with a 90-day enrollment window from the date of the letter. A driver’s license number outlasts a password. It feeds identity-verification checks and account applications for years, which is why the state-by-state counts, 7,870 and climbing across the three states that have published numbers, will keep mattering after the news cycle moves on.

The investigation is ongoing, Fireworks says its findings may still expand, and the fuller accounting of how driver records ended up reachable from an AI vendor’s development environment has not been told. When it is, the test will be whether the industry fixes the retention defaults, credential scoping, and fourth-party blind spots this breach exposed, or files it as another vendor incident and waits for the next one.