In September 2022 an attacker got into Uber's internal tools through a contractor's account, after the contractor approved one of many repeated two-factor login prompts. Uber said public-facing production systems and user accounts were not affected. The lesson for defenders is that a second factor is only as strong as the way it is approved.
What is the timeline?
Everything below is from Uber's own security updates. Times are Pacific.
- 15 September 2022, 6:25 pm. Uber said it was responding to a cybersecurity incident and was in touch with law enforcement.
- 16 September, 10:30 am. Uber said it had no evidence the incident involved access to sensitive user data such as trip history. Uber, Uber Eats, Uber Freight and the driver app were operating. Internal tools taken down as a precaution were returning.
- 19 September, 10:45 am. Uber gave a fuller account of the attack and what it had found.
Uber's investigation was described as ongoing at that point. Later facts may differ from the 19 September update, so read it as a snapshot.
How did the attacker get in?
Uber said an account belonging to a contractor was compromised. It believed the attacker bought the contractor's corporate password on the dark web, after malware infected the contractor's personal device.
The password alone was not enough, because the account used two-factor approval. Uber said the attacker repeatedly attempted to log in, which generated approval requests, and the contractor eventually accepted one. The attacker then had a session.
From there, Uber said the attacker reached other employee accounts and gained elevated permissions to tools including G Suite and Slack. The attacker posted a message to a company-wide Slack channel and changed Uber's OpenDNS configuration so employees saw a graphic image on some internal sites.
What was affected, and what was not?
Uber said the attacker accessed several internal systems, downloaded some internal Slack messages, and accessed or downloaded information from an internal finance tool used to manage some invoices. The attacker also reached the company's bug bounty dashboard on HackerOne, and Uber said any bug reports visible there had been remediated.
Uber said it found no changes to its codebase, and no impact on the production systems that power its apps, on user accounts, on databases holding sensitive data such as card and bank details and trip history, or on customer data held with cloud providers. It attributed the attacker, with belief rather than certainty, to affiliation with the Lapsus$ group, and said it was working with the FBI and the US Department of Justice.
What did Uber do in response?
Uber said it blocked or reset compromised accounts, disabled affected internal tools, rotated keys for many internal services, locked the codebase against new changes, required re-authentication before restoring tool access and added monitoring. It is a useful list because it is concrete: those are the first moves in many identity-led incidents.
What should defenders learn?
Approval prompts are an attack surface. If an attacker can trigger unlimited prompts, the weakest human in the chain decides the outcome. Number matching, phishing-resistant authenticators and rate limits on prompts all narrow that path. Uber's update does not say which method it used, so this is general guidance, not a claim about Uber.
Contractors and personal devices are part of your perimeter. Credentials stolen from a personal device worked on a corporate account.
Reaching one account led to elevated access across several tools. Limit how far a single identity can travel.
Finally, a bug bounty dashboard holds sensitive details. Treat it like a vulnerability database.
What to do
- Switch approval prompts to number matching or a phishing-resistant method.
- Cap prompt attempts per user, and alert when a user receives many in a short window.
- Apply the same authentication standard to contractors, and review their device posture.
- Review which internal tools one account can reach, and cut the excess.
- Rehearse a key and credential rotation across internal services.
- Protect bug bounty and finding data with restricted access.
- Practice the communication steps: a first statement, an update with no unconfirmed claims, then a fuller account.
Safeguard's secrets scanning looks for credentials left in code and pipelines, which narrows what an intruder can find once inside. It does not stop prompt fatigue, and identity controls need to cover that.
Quick check
Was Uber's production data accessed in the 2022 incident?
Uber said no for the systems it named, including production systems for its apps, user accounts and databases with sensitive data. It did report access to internal tools and some internal data.
Does MFA fail to protect accounts?
MFA still blocks most password-only attacks. The weakness here was how the prompt was approved. Stronger methods close that gap.
Sources
Last reviewed: 18 October 2026.
