Start with Identity
Breach teardown · Multiple (Uber and others)

MFA fatigue and push bombing: defeating MFA without breaking it

Affected: Multiple (Uber and others)Disclosed: 2022-09Root cause: Repeated push prompts until a user approves

What happened

In a string of incidents, including the 2022 Uber breach, attackers who already had a valid password bombarded the victim with repeated MFA push notifications, sometimes paired with a message posing as IT. Eventually the tired or confused user tapped approve, and the attacker was in. No vulnerability in the MFA system was exploited; the human was.

Root cause

Simple approve/deny push MFA gives the user a one-tap way to authorize a login they did not start. Combined with a leaked or phished password, an attacker can trigger prompts on demand until one is accepted. Social engineering ("this is IT, please approve") raises the success rate.

The identity lesson

MFA is necessary but not all MFA is equal. Possession-and-approval factors still rely on a human decision under pressure, which attackers can manipulate. The fix is to either remove the human judgment from the loop or make approval impossible to grant to a remote attacker.

How to defend

  • Turn on number matching and context (location, app) in push prompts so blind approval is not possible.
  • Rate-limit and alert on repeated failed or rapid MFA prompts.
  • Move high-value access to phishing-resistant MFA: FIDO2 keys and passkeys, which cannot be approved for a site the user is not actually on.
  • Train help desks and users on the specific "approve this prompt" social-engineering script.

Push fatigue was the beginning, not the end

Number matching largely closed blind approval, and attackers moved on rather than giving up. The 2026 successors do not need the user to approve anything unusual:

  • Attacker-in-the-middle session theft. ANY.RUN traced the Mirage2FA kit across 4,532 organization domains between 2024 and 2026. It does not break the factor: it proxies a legitimate Microsoft 365 login, captures the password and the resulting session cookie, then rides the authenticated session into everything behind SSO.
  • Device code phishing. The victim approves a real Microsoft prompt on the genuine login page, and the attacker receives access and refresh tokens. Every page the user sees is authentic, so there is nothing to spot. See device code flow.
  • Real-time voice relay. An AI voice agent calls and asks for the code, at consumer scale and in the victim's language.

The common thread is that anything a human can read, type, or approve can be relayed. Number matching made the approval harder to grant carelessly; it did not make the factor origin-bound.

The control that generalizes

Phishing-resistant MFA works against all three because the authenticator refuses to produce a signature for any origin other than the one that registered the credential. There is nothing for the victim to recite and nothing for a proxy to forward.

That is not the end of the work. August 2026 research showed passkey protections can be attacked through event logs, sync key custody, and in-session key reuse, all starting from malware on the endpoint. The response is tiering rather than retreat: synced passkeys for the general population, device-bound hardware authenticators for administrators. See passkeys had a hard month.

Guide: Passkeys 101, what is passwordless. Vendors: MFA and passwordless. Glossary: account takeover.

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Compiled from public disclosures and incident reporting; see the linked sources. Independent, community-driven analysis, not a statement of fact about any party. See the disclaimer.