I’ve been doing this long enough to remember when a zero-day was something whispered about in conference hallways (I know I’m old). A rare, expensive, almost mythological artifact, the kind of thing nation-states hoarded, and intelligence agencies paid seven figures to acquire. The barrier to weaponizing a zero-day used to be something…you needed time, expertise, money, and a very specific kind of motivated patience. Not everyone could play that game.

That game just got a lot more accessible.

This week, Google’s Threat Intelligence Group published a report that will probably be cited in security briefings for years (add to your slides now). For the first time, Google documented a confirmed case of a cybercrime group using artificial intelligence to both discover and weaponize a zero-day vulnerability. This was not done in a lab, or a theory on paper….in the wild, against real infrastructure, with a mass exploitation event just waiting to launch fully. The only reason it didn’t wreak havoc is because Google found it first, quietly alerted and patched by the vendor, and disrupted the operation before it could kick off.

We got lucky. Or rather, the defenders got lucky this time. I wouldn’t count on that pattern holding (I never count on that).

Here’s the short version of what Google found: a prominent cybercrime group, currently unnamed, but described by Google’s chief analyst John Hultquist as having a “strong record of high-profile incidents and mass exploitation” (yikes), used an AI model to identify a previously unknown vulnerability in an open-source, web-based system administration tool. Then they used that AI to build a working Python exploit that could bypass two-factor authentication. The plan, as best as anyone can tell, was mass exploitation campaign, not a targeted small grouping of companies target…pray and spray.

Google figured out that AI was involved not because they caught the group in the act, but because the code itself had AI programming tells. The Python script was full of what Google called “educational docstrings”, the kind of over-annotated, hyper-explained commentary that pops out of a language model like a training manual (or so I’m told). There was also a hallucinated CVSS score embedded in the code (well that sounds like AI to me). For those unfamiliar with a CVSS score it is a standardized severity rating assigned to a real, disclosed vulnerability. This one didn’t exist yet, the AI made it up, wrote it into the exploit code with apparent confidence, and the human operators apparently didn’t notice or didn’t care. The structure itself was, in Google’s words, “a textbook Pythonic format highly characteristic of LLM training data.”

In other words… the code looked like it was written by a very capable student who had read every security textbook ever published but had never actually sat across the table from an older penetration tester who would tell them to cut the commentary and ship the thing. That’s not an actual criticism, it’s a forensic fingerprint (people aren’t that thorough, hackers doubly so). It’s a fingerprint that will get harder to spot as the models get better and write more like we do. (soon they’ll include my spelling errors for me!)

Google says they don’t believe Gemini or Anthropic’s Mythos model was involved. That’s notable, partly because both companies have put meaningful effort into guardrails to stop this kind of thing. Which means the group was using something else (maybe something custom created). The ecosystem of models, including fine-tuned, uncensored, or deliberately weaponized variants, is not exactly limited at this point.

Beyond this specific incident, the Google report documented some other concerning patterns from the same reporting period. Notably that North Korean military hacking group APT45 was observed using AI to test and validate thousands of exploits at scale. Another where a piece of malware called PromptSpy was found using Google’s own Gemini to autonomously navigate Android devices, interpreting what was on-screen and generating commands in real time. Then a separate threat group, TeamPCP, ran a sustained supply chain campaign targeting GitHub repositories for tools like Checkmarx and Trivy, embedding credential stealers directly into the software pipelines that developers trust to make their code more secure. (The irony there is genuinely impressive in the worse kind of way.)

The common thread here is that AI is becoming a force multiplier for the attacker. Not a replacement for human judgment (not yet), but a research assistant, a coding partner, a vulnerability scanner that doesn’t sleep, doesn’t bill by the hour, and doesn’t care about your patching schedule.

I want to be careful here, because the security industry has a well-established tradition of taking every new technology and building a twelve-slide deck about how it will end civilization. We’ve done it with cloud, then we’ve done it with IoT and we’ve done it with machine learning. The threat was always real (I want to be clear), the catastrophizing was always a little much, and eventually the industry figured out how to adapt.

I think this is different, not because AI is magic, not because the attackers are suddenly omnipotent. It’s different because of what it does to the economics of exploitation. The traditional model of zero-day discovery required rare expertise. You needed people who could read code and understand memory allocation and think in terms of the edge cases that developers don’t think about. That talent pool is small, not everyone with a computer could do that. It takes years to develop. It is expensive to acquire and expensive to keep. That expense was a friction that (imperfect as it was) created some natural throttle on how many groups could develop novel exploits from scratch.

AI removes that friction…not entirely, not immediately, and not in every case…. but directionally, it lowers the ground floor. A mid-tier threat actor with access to a capable model and a decent dataset of vulnerability research can now run what amounts to an automated vulnerability discovery operation. The work that used to take weeks from a team of skilled researchers might now take one person and a well-crafted prompt a fraction of that time.

Anthropic’s own CEO Dario Amodei said it plainly… AI has created a window, roughly six to twelve months…for organizations to fix tens of thousands of vulnerabilities that models are now capable of finding. After that, adversaries will be using the same capability at industrial scale, and the window closes.

I don’t know if six to twelve months is exactly right… nobody does (and if they tell you they do…they’re a lair…or in sales) but the direction we’re moving it is not ambiguous.

Let me put on the security leader hat for a moment, because “the threat is evolving” is not a strategy and I’ve often found panic not to be a particularly useful management tool. There are things you can actually do. Things that, frankly, you should be doing anyway… and now you have a very pointed reason to stop deprioritizing them.

First: treat your attack surface like the threat actors already have a better map of it than you do. I say thing because they might. The immediate implication of AI-assisted vulnerability discovery is that the gap between “vulnerability exists” and “vulnerability is known to an attacker” just got shorter. Your traditional assumption…that you have a window between a CVE being published and an adversary developing a working exploit… is no longer reliable. If an attacker can use AI to find vulnerabilities you haven’t disclosed yet, the window between discovery and exploitation can now be (and should be) zero on your side of the equation.

This means your vulnerability management program needs to stop being a queue and start being a triage operation. Not every CVE is equal, not every patch can be deployed in 24 hours. I’ve been in environments where the patch backlog numbers in the thousands, and the team is doing the best they can with the time and resources they have. I understand the constraint for some teams, but the risk calculus just shifted. Anything internet-facing, anything that handles authentication, anything involved in your most sensitive data flows, those need to be at the front of the line, on a compressed timeline, regardless of whether a proof-of-concept has been published yet.

Second: multi-factor authentication is not a finish line. This specific exploit was designed to bypass 2FA. That is not an argument against using 2FA (please, everyone, still use 2FA/MFA) but it is an argument against treating MFA as a solved problem (I’ve been saying this for years). The specific mechanism matters. Time-based one-time passwords delivered over SMS are not the same as hardware security keys. Push notification fatigue attacks are real and documented. MFA configurations that hardcode trust exceptions into authentication flows like the one Google described in this specific case, are the kind of thing that nobody thinks about until somebody finds it from the outside.

A real authentication review looks at how trust is granted, where exceptions have been carved out, and what happens when a session is presented in an unusual way. Most MFA reviews I’ve seen in my past just confirm that a second factor exists…that’s not the same thing.

Third: your AI posture needs a security framework before your AI posture has an incident. I feel like a lot of organizations don’t take security seriously, until after an incident.  I know this is the part where some of you are already nodding because it’s on the roadmap. I know others are nodding because they have no idea what their AI posture actually is and nodding seems safer than admitting it. Both are understandable.

The practical point is this… if your organization is using AI tools, and at this point, if you work in technology, you almost certainly are, you need visibility into which models, which data, which workflows. Agentic AI systems that operate autonomously and have elevated permissions to internal systems are exactly the kind of target the Google report describes as attractive to malicious actors. An agent that can read your source code, execute commands, and access cloud credentials is a very interesting target for an adversary who can manipulate what that agent sees or does. You cannot have a serious conversation about securing AI systems if you don’t know what AI systems you’re running.

Fourth: get your threat intelligence program off the brochure and into practice. Google found this because they were watching. Mandiant and others are watching. The community of threat intelligence analysts who track groups like TeamPCP and monitor dark web leak sites and catalog the techniques of APT45, they do genuinely useful work. The question is… is whether your organization is using that intelligence to inform decisions, or whether the threat intel feeds are generating alerts that go somewhere to be quietly ignored.

In my past I’ve been in environments where the SIEM is alive with telemetry and the threat intel platform is full of indicators of compromise, and yet the security team’s actual understanding of the threat they face is roughly equivalent to reading the newspaper. Detection tells you something happened, understanding tells you what it means in the context of your environment. Those are different investments.

Fifth, and I’ll say this plainly because people don’t say it plainly enough: assume the attackers are already in your environment somewhere. Not because I’m trying to be dramatic. Because this is a foundational shift in how you orient your program. The perimeter model… where your job is to keep the bad guys out…is a comforting fiction that we’ve been letting organizations operate under for too long. If a sophisticated group with AI-assisted vulnerability discovery capability decides your organization is worth their time, the question is not whether they will eventually find an entry point, the question is what they will find when they get there, how long it takes you to notice, and how much blast radius they can generate before you catch it.

Zero trust architecture….network segmentation…least privilege access…comprehensive logging… that covers not just the edge but internal lateral movement. These are not new ideas. They are the right ideas, and they matter more now than they did last week.

Here’s what I keep coming back to. The Google report is being received in a lot of circles as a warning about what attackers can do with AI. And it is that. But it’s also something else. The same capabilities that let a threat actor use AI to find vulnerabilities faster…the code analysis, the pattern recognition, the ability to process massive codebases and identify edge cases…those capabilities exist on the defensive side too. Google is already using AI for exactly that purpose. Mozilla has been using it to find bugs in Firefox. Anthropic built Mythos specifically, in part, for vulnerability research.

The race is real. The attackers have access to AI. So do you. The question is whether your organization is actually using that access to close vulnerabilities, or whether the AI conversation in your boardroom is still mostly about productivity and cost savings and not about the security implications of a world where every attacker now has a research assistant that never sleeps.

I admit I don’t have a tidy answer to that, I wish I did. I think the honest version is that we are in an early and uncomfortable period where neither side has fully figured out how to maximize what AI means for their operation. The attackers are ahead in some dimensions. The defenders are ahead in others and for the next year or two, the gap will widen or narrow based on who moves faster.

The organizations that treat this as a reason to accelerate, to patch faster, to review authentication architectures more thoroughly, to actually operationalize their threat intelligence, I think will be better positioned. The organizations that read the Google report, add it to a file of concerning trends, and wait for their next security assessment to figure out what to do about it will eventually get to explain that choice to someone they really didn’t want to have that conversation with.

The machine that finds the vulnerability is already running. The only question is whose side it’s on when it finds yours.