In April, Anthropic announced Claude Mythos Preview. The new AI model, which wasn’t explicitly trained to identify and exploit zero-day vulnerabilities, could do exactly that, making waves in the cybersecurity space and the broader tech industry. Since then, Anthropic has released models specifically for cybersecurity, as have Google, OpenAI, and Microsoft. If you’re a vulnerability researcher able to pay for these models, the most worrying part of your job is that you can lose access: either due to the government or the model makers themselves. You could easily end up in a situation where your competitors can access frontier AI models, and you can’t.
It turns out, however, that you don’t need a fancy AI model to effectively hunt for zero days. If you understand vulnerability research and how to effectively coordinate older models, you can find new zero-day vulnerabilities and produce exploits for n-days within hours. In fact, we used pre-Mythos models to find novel vulnerabilities using code scanning frameworks, with no human in the loop. Here’s what we learned.
Divide and conquer with program slices
LLMs are fantastic at taking small segments of code, or a description of a specific problem, and finding an interesting solution. If you give an LLM access to a large codebase and ask it to find security problems, however, it will happily ingest every file in the repository trying to find every flaw. This will not only blow through your token budget and render any work you do in your framework moot, but it will also quickly fill up your model’s context window with code it doesn’t need.
The context window has to contain not just the prompt, but your system prompt, your MCP, and everything else the AI model needs to respond to your prompt. If you point Claude Code or Codex at a codebase and say, “find me bugs,” they sometimes find bugs, but the results are not repeatable. Chances are most of the code is irrelevant to the vulnerability in your complex codebase, but you of course don’t know which parts are important until you’ve found the vulnerability. For more complex bugs that require chaining multiple steps, your framework must keep the right parts of the code in its memory at the right time, or somehow intelligently retrieve it when needed. In our experience, such a setup rarely finds interesting bugs.
The latest AI models don’t offer a step change in cybersecurity that miraculously solves this problem. They are simply better at navigating code bases and finding the right code to look at. Thankfully, traditional code scanning frameworks already have tools for finding related code (we call this a program slice), so you don’t need to waste tokens doing that. Program slices are similar to when your IDE or LSP tool uses features like “find implementation” or a call graph to group together all the functions called by the current function. You can use these mature, well-tested tools to solve this diluted context issue for large codebases.
Inspired by nooperator’s work on Slice, we successfully applied this approach to find vulnerabilities in WordPress plugins, which we chose as our target because we wanted somethingcked over by bug bounty professionals
Here are three tips for when you want to build your own pipeline:
- Write broadly scoped rules to look for “interesting things” and use a lightweight triage agent to filter your findings, so that you can err on the side of false positives rather than risk missing bugs.
- Apply basic taint tracking techniques to rule out obviously safe functions and statically verify that the code is safe to run, so that you can save tokens by not having to pass anything definitely safe to the agents.
- Pass slices that appear to be exploitable to a heavyweight agent, so that the entire call context fits into memory and the agent can focus on whether the case is exploitable.
At the later stage of the triage, give the agent access to all the code and a live version of the app you’re testing. We gave the heavyweight agent a WordPress instance where it could install plugins, create users, change settings, and do anything else it needed to. If you can give your AI system a pass/fail task that it can test itself, you all but eliminate hallucinations because it can test its work as it goes. Exploits are perfect for this because if you exploit something, you either get access or you don’t, you get the data or you don’t, and so on.
You can experiment with different code scanning engines, triaging flows, and models. We learned that prompts are a lot more important than you’d think for cheaper, older models, but your mileage will vary depending on the model.
Our first interesting finding was CVE-2026-3985, a SQL injection vulnerability in the Creative Mail plugin. The proof-of-concept script showed it was high impact (an attacker could get read access to the database) and required multiple steps and requests to exploit (a second plugin, WooCommerce, had to already be installed too).
This was just the first. We have many more vulnerabilities that are either reported to the vendor, under disclosure, or in the pipeline.
What no Mythos required means for AI vulnerability research
Attackers are already using existing tools to feed AI tools focused, targeted inputs, dramatically increasing the signal-to-noise ratio and their chances of finding vulnerabilities quickly. Meanwhile, defenders only have more attack surfaces to manage, making automated discovery and patching of vulnerabilities even more important. Attackers and defenders are only going to increasingly use AI models, accelerating the cat-and-mouse game of finding, exploiting, and patching vulnerabilities.
If you’re a defender, don’t bend over backwards trying to access and overspend on the latest and greatest model. AI is accelerating vulnerability discovery for attackers and defenders alike, and your exposure management needs to keep pace.
