Zero-Day with AI: The Google Case, Its Markers, and What We Don't Know
Google GTIG published a report claiming to have detected the first AI-generated zero-day. The evidence is thinner than it seems, and this isn't the first time this claim has been made.
On May 11, 2026, Google Threat Intelligence Group published a report on the use of artificial intelligence in offensive operations. Among several findings —autonomous malware, AI infrastructure attacks, disinformation campaigns— one dominated the headlines: "for the first time, we have identified a threat actor using a zero-day exploit that we believe was developed with AI."
The evidence presented consists of stylistic markers in the code: a CVSS score that doesn't exist in any CVE database, docstrings with textbook formatting characteristic of LLMs, and a semantic vulnerability —a hardcoded trust exception— that Google points to as consistent with current language model capabilities.
None of those markers distinguish between "an LLM autonomously discovered the vulnerability" and "a human used an LLM to write the code." That distinction matters, and the report does not address it.
The Evidence: Three Markers
Google stated it has "high confidence" that an AI discovered and weaponized the exploit. Its evidence is three markers in the Python code.
1. The CVSS That Doesn't Exist
The script contained a CVSS score not found in any CVE database. Google argues no human attacker would include an invented severity metric in their own exploit. That's true. But it doesn't prove AI found the vulnerability. It proves the exploit code —or part of it— was generated by an LLM. These are two different things.
An attacker could have manually identified the logic error in the 2FA flow and then asked an LLM: "write me an exploit for this." The result would have exactly the same fingerprints: invented CVSS, clean code, explanatory comments. Google's evidence does not distinguish between "AI found the vuln" and "a human used AI to write the exploit."
These hallucinated CVSS scores are known behavior in LLM responses when asked to generate code: they tend to include metadata that looks real but isn't. Their presence indicates the code passed through an LLM, but does not determine whether the model discovered the vulnerability or simply wrote the code a human asked for.
2. Educational Docstrings and Textbook Format
The exploit had overly long comments and clean structure. Google describes it as "highly characteristic of LLM training data". There is no difference between "an attacker asked an AI to generate the exploit" and "an AI discovered the vulnerability and generated the exploit" in terms of the resulting code format. The output is the same.
These fingerprints can be removed with additional instructions to the model —for example, requesting code without comments or metadata— suggesting that detection windows based on this type of marker are inherently limited.
3. The Semantic Logic Flaw
The vulnerability was not a buffer overflow or SQL injection. It was a semantic logic error: the developer hardcoded a trust exception in the 2FA flow. Google argues that fuzzers and static scanners don't detect this type of bug.
That's true. But an experienced human doing code review also detects that error. It is not an exclusive AI capability. Google notes it doesn't know which model was used and that it wasn't Gemini or Mythos.
Not the First Time
Google presented its finding as "the first time." Similar precedents exist and are worth considering.
| Date | Reported by | Headline | What actually happened | Source |
|---|---|---|---|---|
| Nov 2023 | Check Point | "AI found a zero-day" | LLM used as code review assistant. Humans confirmed. | [2] |
| Jan 2026 | Check Point | "Malware almost entirely made by AI" | Single person using AI IDE. Never deployed. | [3] |
| Mar 2026 | MAD Bugs | "Claude wrote a kernel RCE" | Claude exploited known CVE. Limited lab. | [4] |
| May 2026 | Google GTIG | "First AI zero-day" | Code with LLM markers. Vendor patched. | [1] |
A Concrete Test
On May 17, 2026, using a 2 billion parameter model (huihui-qwen3.5-2b) running on a laptop, we generated the same style of code Google used as evidence:
"""
CVSS Score: 9.7 - Critical
"""
class Hardcoded2FAExploit:
def _hardcoded_trust_exception(self, user_input):
"""Implements the hardcoded exception.
Allows access without verifying the OTP token."""
return True The result includes an invented CVSS, educational docstrings, and a textbook structure —the same markers Google used in its analysis.
Google detected this case because the code contained stylistic markers that revealed its LLM origin. If Google, with its access and telemetry, identified the exploit through these fingerprints —what are the rest of the CTI teams missing?