Something changed on 11 May 2026. Not subtly. Definitively.
Google’s Threat Intelligence Group disclosed it had detected and disrupted a planned mass exploitation campaign built around a working zero-day in a widely deployed open-source administration tool. The exploit was a Python script targeting a 2FA authentication flow. A large language model wrote it. Not assisted a human in writing it. Wrote it.
That’s the first confirmed case of AI-generated exploit code incorporated into a live campaign, and it moves the LLM-in-offensive-operations question out of the theoretical column permanently.
What the Exploit Actually Did
The target was a logic flaw in a 2FA implementation, not a memory corruption issue, not a kernel exploit. An attacker who knew the right sequence of authentication requests could skip the second-factor check entirely. The kind of bug that surfaces in code reviews when someone’s actually looking, and gets missed when they’re not.
The exploit itself was clean. Well-structured Python, readable, functional. Google’s analysts flagged it as LLM-authored based on several specific characteristics:
Educational docstrings. Every block of code came with explanatory comments in the register of an LLM trying to appear instructional. Human exploit developers don’t write like that; they’re terse, idiosyncratic, impatient. This read like a tutorial.
A hallucinated CVSS score. The script’s header cited a CVSS score that doesn’t correspond to any published CVE. The model generated a plausible-looking score as part of its framing. It was wrong. Doesn’t mean the exploit didn’t work.
Uniform code style. Consistent indentation, naming conventions, error handling: none of the organic variation you get from a human who’s been writing code for years with their own habits. Conspicuously clean.
None of those fingerprints made the exploit less functional. The 2FA bypass logic was technically sound. It had been tested against a live target before Google detected the campaign. That matters. The actor wasn’t just asking an LLM to write code and hoping. They validated it.
The Scale of What Was Planned
This wasn’t a targeted intrusion. The actor intended to scan at scale and exploit every internet-exposed instance of this admin tool they could find. Tens of thousands of potentially vulnerable deployments, across healthcare, financial services, critical infrastructure. The kind of opportunistic mass exploitation campaign that generates a wave of incidents across multiple sectors simultaneously.
Detection came through threat intelligence collection, underground forum monitoring, and analysis of staging infrastructure the group had begun assembling. Google coordinated with the software maintainers to get a patch out on 10 May, one day before the advisory dropped. The window between the actor acquiring a working exploit and Google’s detection was narrow. Uncomfortably so.
Why This Is the Threshold That Matters
Researchers have been demonstrating LLM-assisted vulnerability discovery in controlled environments for a couple of years. That’s not what happened here. An actor used AI tooling to develop a functional exploit and built an operational campaign around it. That’s a different thing.
The barriers to exploit development have always been meaningful. Writing a reliable 2FA bypass requires understanding the authentication flow you’re attacking, having a live environment to test against, and producing deployable code. LLMs compress the time and skill cost of the first and last of those requirements substantially. They don’t eliminate the constraint entirely (complex kernel exploits are still beyond current LLM capability), but for logic flaws in web authentication flows, the capability gap has narrowed.
The practical effect isn’t that every actor now has zero-day capability. It’s that the population of actors capable of producing functional exploits for a specific class of vulnerability (logic flaws, auth bypasses, web application injection issues) has expanded. How much? We don’t know yet.
The hallucinated CVSS score is operationally useful right now. It’s a detection marker. Analysts triaging post-incident artefacts should add LLM fingerprint analysis to their process while these markers are still reliable. They won’t be forever: actors will learn to suppress them, or fine-tune models on human-authored code to strip the tells. But for now, they’re there.
What to Do
Apply the patch. If your organisation runs this admin tool, confirm you’re on the version released 10 May. Assume active scanning is ongoing. Detection caught the campaign before launch, but the exploit exists and the tooling isn’t going away.
Audit your 2FA implementations. Logic flaws in authentication flows are common and chronically underscrutinised. Any internally deployed tool with a 2FA implementation that hasn’t been independently assessed is a candidate.
Retire the assumption that novel exploit code requires APT-level resources. LLM-assisted exploit development is now a demonstrated operational capability. It belongs in the threat models of organisations that have been reassuring themselves that custom tooling was beyond the reach of lower-tier actors.
Add LLM fingerprint checks to incident response workflows. When you’re analysing attacker tooling post-incident, look for the tells: educational comments, hallucinated citations, unnaturally consistent style. This signal has a finite shelf life, but it’s live right now.