Google’s Threat Intelligence Group says it observed a financially motivated actor use an AI tool to develop a zero-day two-factor authentication bypass in a third-party product, with the exploit intended for mass exploitation.[1] The affected vendor was not named in Google’s public write-up, and Google said it is working with the vendor before disclosure.[1] That makes this less of a patch-now alert and more of a practical warning: attackers are using AI to speed up the search for logic flaws in authentication workflows.
According to Google, the actor did not use Gemini. The company said the attacker used another AI tool to develop a zero-day vulnerability that could bypass 2FA protections, then planned to exploit it at scale.[1] The Hacker News summarized the case as the first known example, publicly described by Google, of AI being used to develop a zero-day vulnerability for exploitation in the wild.[2]
The important nuance is that this is not described as “AI breaks all MFA.” Google’s wording points to a specific vulnerability in a third-party product, not a universal failure of two-factor authentication.[1] Still, it lands in the same risk family as AiTM phishing and session theft: once an attacker has valid credentials, any weakness around enrollment, recovery, device trust, token validation, or step-up checks can become the actual path into the account.
That is why this story is useful even without the vendor name. We recently covered a Microsoft AiTM phishing campaign that targeted session cookies at large scale, and a fake AI repository infostealer that tried to steal tokens from developer machines. In all three cases, the boring-looking identity layer becomes the real prize. Passwords, MFA prompts, sessions, and recovery flows need to be treated as one system, not separate controls.
What defenders should check
Because the vulnerable product is not public yet, administrators should avoid hunting for a named CVE that does not exist in the report. A better response is to review the parts of authentication that often sit just outside normal MFA testing. Those areas are where a “valid credentials plus logic bug” chain can become dangerous.
| Area | What to verify |
|---|---|
| MFA enrollment and reset | Confirm that attackers cannot enroll a new device, reset MFA, or downgrade the factor after password login without strong reauthentication and audit logging. |
| Recovery and backup codes | Review recovery-code issuance, one-time-code reuse, helpdesk overrides, email recovery, and identity-proofing exceptions. These are common side doors. |
| Trusted-device logic | Check whether device trust can be replayed, copied, or granted before the full MFA decision is complete. |
| Session validation | Force step-up checks for sensitive actions, new geography, new device fingerprints, suspicious IP reputation, and impossible-travel patterns. |
| Telemetry | Log MFA challenge creation, challenge completion, failure reason, factor changes, session issuance, token refreshes, and administrative overrides in one place. |
The most useful immediate question is simple: can a user session be issued before the MFA state is fully and correctly verified? If the answer is unclear, that flow deserves a review. Attackers do not need a cinematic bypass if they can find a small ordering bug, stale trust flag, weak recovery branch, or API endpoint that treats “password accepted” as “authentication complete.”
Security teams should also watch for signs that attackers are testing authentication flows repeatedly rather than simply brute-forcing passwords. Look for repeated partial logins, abandoned MFA challenges, unusual recovery attempts, new trusted-device registrations, sudden factor changes, and sessions created from automation-like user agents. Session anomalies matter because a successful bypass may look like a clean login after the exploit step has already happened.
Google’s broader point is that AI is not only being used for phishing text or malware scaffolding. It can help attackers reason through code, APIs, and authentication state machines faster than before.[1] For defenders, that raises the bar for testing identity controls. MFA remains necessary, but the surrounding workflow must be tested like application logic, with abuse cases, state transitions, recovery paths, and session issuance all included.
References
- Google Threat Intelligence Group. “Adversarial Misuse of AI: Vulnerability Exploitation and Initial Access.” Google Cloud Blog, May 11, 2026. https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access
- Ravie Lakshmanan. “Hackers Used AI to Develop First Known 2FA-Breaking Zero-Day Exploit, Google Says.” The Hacker News, May 11, 2026. https://thehackernews.com/2026/05/hackers-used-ai-to-develop-first-known.html
Leave a Comment