Google Catches the First AI Built Zero-Day and Stops a Mass Attack Before It Starts

Google caught a criminal group that used AI to find a zero-day in a popular web admin tool and had a working exploit ready for a mass attack against thousands of systems. Google has never named the tool. The attack never launched. What gave them away was a CVSS severity score inside the code for a vulnerability that has never been officially rated. The AI made up a number that does not exist.

Google’s Threat Intelligence Group (GTIG) is a team that combines Google’s own security researchers with the people from Mandiant, a company that gets called in when organizations get hacked. On May 11, 2026 they published a report that documents something the security industry has been warning about for years: attackers using AI not just to write better phishing emails, but to actually find vulnerabilities in software and build working attacks from them.

The target was a popular open-source tool that system administrators use to manage servers and services through a browser. Google has not named the tool or the company behind it. The vulnerability the AI found was a bypass for two-factor authentication. Two-factor authentication is the second step that comes after your password, the code your phone sends you, or the tap you do to confirm it is really you logging in. The bug meant that someone who already had a working username and password could skip that second check completely.

The bug was not in the two-factor system itself. It was in how the application decided who to trust. A developer had written a rule that said: if this condition is present, treat this user as already verified. That shortcut left a gap in the login process. This kind of bug is called a semantic logic flaw. The code works exactly as written, nothing crashes, nothing looks broken, but what the code does is the opposite of what it was supposed to do. Normal security scanners look for crashes and bad inputs. They are not built to read through application logic and notice where the result no longer matches the intention. A language model can do that, and in this case, one did.

The group behind the exploit was planning to use it in a mass attack against a large number of systems. Google describes them as a well-known group with a history of large-scale attacks. Google worked with the vendor to get the bug patched before the campaign could start, and their action likely stopped the attack before it reached any targets.

Here is what the code actually contained, and why it gave the attackers away.

The first was the comments. In Python, you can add a block of text inside a function that explains what it does, step by step, like a tutorial. Developers do that in code they want other people to learn from. Nobody building an attack tool does that, because you do not want your malware to walk an investigator through exactly how it works. This script was packed with them.

The second was a made-up severity score. There is a scoring system in security called CVSS that rates how serious a known vulnerability is, from 0 to 10. Those scores are only assigned after a bug has been officially reported and reviewed. This was a zero-day, a vulnerability the vendor did not know about yet, so no score had ever been assigned. The AI put one in anyway, a confident and specific number for a bug that does not exist in any official database anywhere.

The third was the ANSI color class. This is a specific coding pattern that shows up in AI-generated Python code, used to add colored text to a terminal window. Experienced exploit developers almost never write it that way.

The fourth was the overall look of the code. Clean formatting, detailed help menus, organized argument handling, the kind of thing you write when other people are going to read your work. Attack tools are not written to be readable. They are written to work.

This is what that pattern looks like. The actual exploit code has not been made public, but GTIG described exactly what was in it. This is an illustration of what they found:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

def bypass_two_factor(session, user_id):
    """
    Triggers the hardcoded trust condition in the login flow
    to skip the 2FA verification step entirely.

    The application contains a logic flaw: a specific internal
    condition, when triggered from outside, marks the user as
    already verified without completing the second check.

    CVSS Score: 8.9 (HIGH) - AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

    Args:
        session (requests.Session): Active authenticated session
        user_id (int): Valid account identifier

    Returns:
        bool: True if 2FA was successfully bypassed
    """

The CVSS score in that block does not correspond to any registered vulnerability anywhere. Nobody assigned it. The model put it there because every security write-up it had ever trained on included one. A person writing a real attack tool has no reason to include a severity rating that does not exist.

Google confirmed that Gemini was not used. They say the AI likely helped both find the vulnerability and turn it into working code. They did not have access to the attacker’s prompts or model logs. Which model the attackers used remains unknown. The code is the only evidence they have.

The exploit was also not fully finished. The AI made mistakes that got in the way of the attackers’ plan. Google’s action probably stopped the campaign, but the attackers had already shown that this approach works, even if they did not get it right yet.

In cybersecurity, working out who is actually behind an attack is one of the hardest things to do. IP addresses can be spoofed. Tools get shared between different groups. Languages in source code can be used deliberately to mislead. What the GTIG report documents clearly is how these techniques work and what the patterns look like in practice. Who is sitting behind each operation is a different question, and one that goes beyond what is publicly verifiable.

The group behind this exploit is not the only one working this way.

North Korea’s APT45 is a state-sponsored hacking group linked to the Reconnaissance General Bureau, North Korea’s primary intelligence organization. Google has been watching them send thousands of prompts to AI models that work through CVEs one after another. A CVE is a published report that documents a known vulnerability with an official reference number. APT45 feeds them into AI models that test whether a working attack can be built from each one. This is not someone sitting at a keyboard trying things manually. It is a pipeline that runs through vulnerability data at a speed and volume that would be impossible to manage any other way.

A China-linked group tracked as UNC2814 uses a technique called expert persona prompting. Instead of asking an AI directly how to attack something, the operator tells the model to act like a senior security researcher, then asks it to look through router firmware and industrial software for ways to run code on a device without needing to log in first. The targets Google documented include TP-Link router firmware and OFTP, the Odette File Transfer Protocol, a file transfer standard used in industrial environments including the automotive sector.

Attacks on Ukrainian organizations linked to Russia included two malware families called CANFAIL and LONGSTREAM. Both use AI-generated filler code to hide what the malware actually does. CANFAIL contains blocks of code that look like they belong there but do nothing at all, put there to confuse analysts and throw off automated detection tools. LONGSTREAM contains routines that check for daylight saving time over and over again, which has nothing to do with what the malware is actually doing.

China-linked groups have also been using a GitHub repository called wooyun-legacy, built as a Claude Code skill plugin, that contains more than 85,000 real vulnerability cases from the Chinese bug bounty platform WooYun, collected between 2010 and 2016. Loading that data into a model before it starts working gives it the background of tens of thousands of documented real-world bugs, which makes it much better at spotting similar problems in new software.

Then there is PROMPTSPY, and this one works differently from everything else in the report.

PROMPTSPY is an Android backdoor that ESET researchers found first, but Google’s team uncovered capabilities in it that nobody had reported yet. The malware contains a module called GeminiAutomationAgent. When it needs to do something on an infected phone, it reads the current state of the screen using Android’s Accessibility API. That is the system that apps like screen readers use to understand what is visible on the display. It packages everything it sees into a structured file and sends it to the Gemini API. The model sends back instructions: what to tap, what to swipe, and exactly where on the screen. The malware carries out those actions as if a person were operating the phone.

1
2
3
4
5
6
7

Module:    GeminiAutomationAgent
Model:     Gemini API (hardcoded)
Input:     Android screen state via Accessibility API
Output:    JSON with tap and swipe instructions
C2:        54.67.2[.]84 (VNC protocol)
Origin:    Chinese-speaking development environment
Targets:   Argentina (based on language patterns in the code)

What this means in practice: the malware can navigate any Android phone without knowing the layout of that specific device in advance. It pins itself in the recent apps list so the user cannot swipe it away. The malware survives normal reboots. The only way to remove it is to restart the device into Safe Mode, where third-party apps can be uninstalled normally. It watches for when the user enters their PIN or unlock pattern and records it so it can get back in later. It puts an invisible layer over the uninstall button so the user cannot tap it through normal means.

While AI was being used as a weapon in the cases above, the same report highlights that a criminal group was going after AI infrastructure directly.

LiteLLM is a Python package that sits between applications and AI providers. If your app needs to talk to OpenAI, Anthropic, Google, or dozens of other AI services, LiteLLM handles that connection through a single interface. Organizations like Stripe, Netflix, and Google use it. It gets downloaded about 97 million times a month, and because it sits in the middle of all those AI connections, it holds API keys for every provider an organization uses.

In March 2026, a group called TeamPCP compromised it. They did not go after LiteLLM directly. They went after Trivy first. Trivy is an open-source security scanner that many development teams use to automatically check their code for vulnerabilities as it is being built. LiteLLM used Trivy in its build pipeline without pinning it to a specific version. When TeamPCP tampered with Trivy, the next time LiteLLM’s build process ran, it pulled the compromised version, which stole the credentials LiteLLM used to publish packages to PyPI. PyPI is the central place where Python developers download packages from.

With those credentials, TeamPCP published two backdoored versions of LiteLLM on March 24, 2026. Version 1.82.7 went up at 10:39 UTC. Version 1.82.8 followed thirteen minutes later and was more dangerous: it used a .pth file, a mechanism that runs code every time any Python process starts, whether or not LiteLLM is ever imported. A developer running tests, a build system starting up, a notebook opening, all of it would trigger the payload automatically.

What ran was a three-stage credential stealer. It grabbed SSH keys, cloud credentials for AWS, Google Cloud, and Azure, Kubernetes configuration files, database passwords, .env files containing API keys, and crypto wallet files. Everything got encrypted and sent to a server at models.litellm[.]cloud.

PyPI pulled the packages within about three hours. With 97 million monthly downloads, three hours was enough.

1
2
3
4

Affected versions:  1.82.7 and 1.82.8
Last clean version: 1.82.6
Safe to use:        1.82.9 and higher
Exfiltration C2:    models.litellm[.]cloud

If you had either version installed at any point on March 24, 2026, treat every credential on that system as exposed and rotate all of it: cloud keys, API tokens, SSH keys, database passwords, everything.

Google is running its own AI tools in response. Big Sleep, built by Google DeepMind and Google Project Zero, automatically searches through software for unknown vulnerabilities. It already helped Google find a critical bug in SQLite that attackers were about to use, and the attack was stopped before it got off the ground. CodeMender is a newer tool that goes a step further: it finds a vulnerability and then rewrites the affected code to fix it. All changes are reviewed by a person before they go out.

The same technology running these attacks is the technology being used to stop them. Which side moves faster is the only thing that matters now.

Ten days before the GTIG report came out, the UK’s National Cyber Security Centre published a warning about what they called a vulnerability patch wave. Their message: as AI tools get better at finding flaws in software at scale, both defenders and attackers will be using them. That means a large number of vulnerabilities will get discovered and disclosed in a short period. Organizations that are not set up to push patches quickly will fall behind. Their advice was to start with whatever is directly accessible from the internet, get that patched first, and then work your way inward from there.

If you are running web-based administration tools, there are a few things worth doing.

• → Update every open-source admin tool to its latest version. The vendor here has pushed a fix, and this type of bug, a logic error in how login checks are handled, is now a confirmed target for attackers.
• → Look at whether hardware security keys are realistic for important accounts. Keys that use the FIDO2 standard require the physical key to be present at login. A bypass that tricks software into skipping a verification step does not work against a system where a physical device has to respond to a mathematical check.
• → Go through any custom authentication code in your stack and look for shortcuts. The bug here was a condition that marked certain users as already verified without actually completing the check. Any login logic that contains special cases is worth a close look.
• → For security teams: comments that read like tutorials, CVSS scores in exploit code for bugs that have never been officially reported, and well-formatted Python scripts with detailed help menus are now signals worth adding to your detection tooling.

Understanding how authentication bypass works, how attackers get into systems and stay there, and what defenders can actually do about it is exactly what my ethical hacking course covers step by step:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: Google Threat Intelligence Group | ESET Research | National Cyber Security Centre