We built a vulnerability vending machine: AI tokens in, zero-days out

AI is changing how vulnerability research gets done, but most of the conversation is still theoretical: what a model might eventually be capable of, rather than what it can actually find today.

We wanted to answer a more practical question: using the models already available to us right now, how far can AI take us in finding real, exploitable vulnerabilities in production software?

This piece details how the team at Intruder is using LLMs to find novel vulnerabilities using code scanning frameworks alongside current, pre-Mythos models.

We walk through a remote, multi-stage SQL injection zero-day we discovered in a WordPress plugin with over 300,000 users — fully automated from discovery through exploitation, with no human in the loop.

The focus problem: why pointing AI at a whole codebase doesn't work

The big problem when pairing AI with a code scanner is focus. LLMs are excellent at taking small segments of code, or a description of a specific problem, and finding an interesting solution. But point one at a large codebase and ask it to find security issues, and it will try to ingest every file in the repo.

That's expensive in tokens, and worse for accuracy: by the time the model is halfway through, its context is full of irrelevant code, and the bug you actually want is buried in noise.

For more complex bugs that require chaining several steps together, you're then relying on the framework to keep the right context in memory, or retrieve it intelligently when needed. In our experience, that produces poor output rather than real and interesting bugs.

Traditional code scanning frameworks already solve this. We use a technique we're calling a program slice, which is similar to when an IDE or LSP tool uses features like "find implementation" or a call graph to find all functions called by the current function. These are mature, well-tested tools, and they sidestep the diluted-context problem entirely.

Our pipeline: from codebase to working exploit

We built a pipeline that takes a codebase, runs it through a code scanning engine (we use Joern), generates slices of code relevant to each finding, and uses an LLM to triage and exploit the issue. The design was inspired by nooperator's work on Slice, though we use Joern rather than CodeQL and designed the slicing algorithm quite differently to handle the specific vulnerability classes we’re looking for. 

We pointed it at the top 200 WordPress plugins — code that's already heavily picked over by bug bounty researchers, so finding something real there would mean the process can compete with skilled humans.

First, Joern runs against the codebase with rules designed to flag broadly "interesting" patterns — this is deliberately loose to avoid creating rules that are too specific and might miss bugs. Since we have the triage agent filtering later anyway, we can err on the side of false positives.

For this experiment we were after unauthenticated WordPress plugin attack surface, so we had Joern identify every place a script can be affected by user input: REST routes, template hooks, nopriv AJAX calls, and so on.

For each WordPress hook, Joern generates a slice: the function the hook calls, every method that function calls, and so on down the chain. Basic taint tracking rules out obviously safe functions, such as SQL and XSS inputs that go through a known-safe sanitizer. Where we can verify statically that the code is safe to run, we drop those passing onto an LLM.

Each slice goes to a lightweight triage model (Sonnet, in our tests) to filter out the obviously uninteresting: hooks that are meant to be public and have no side effects, for example.

What's left goes to a heavier model (Opus) to assess exploitability, with the full relevant call context in memory so it isn't hunting through unrelated source.

Anything judged exploitable goes to a final exploitation agent to try and write an exploit. This agent has access to full source again (if needed) since it can now use targeted searches to find relevant code, and it will also spin up a Docker container running the software to test while developing.

The first vulnerability: a blind SQL injection in a popular WordPress plugin

The first bug the pipeline vended was CVE-2026-3985, a SQL injection vulnerability in the Creative Mail plugin. It stood out to us for a few reasons: 

• It’s high impact, giving an attacker read access to the database (including admin hashes and secret tokens!)

• It requires multiple chained requests to exploit, making it less likely to be detected by traditional tooling

• The root cause was hidden from the developer's own static analysis tooling by a mistake in their code

Exploitation does require WooCommerce to be installed alongside Creative Mail, but since WooCommerce is a common reason people run WordPress (over 7 million active installs), the combination is common.

The exploitation agent one-shotted a working proof-of-concept, producing a check to confirm the issue existed and a full extraction method capable of pulling password hashes from the database.

This vulnerability was also found independently by Dmitrii Ignatyev of CleanTalk Inc., who reported it to Wordfence.

The plugin has been pulled from the WordPress store pending review; if you're running Creative Mail alongside WooCommerce, disable it until a patch is available.

For the full technical details, see our write-up.

Discovery is getting faster. Detection has to keep up

This is just the first vulnerability the pipeline has vended. We're already finding more and reporting them to affected vendors (those are still under disclosure). 

AI clearly has a growing role to play in vulnerability research, and the work now is building the frameworks to get the most out of current models. Attackers are already using similar tooling to feed AI high-signal input, which means the same speed advantage we've demonstrated here isn't unique to defenders.

Vulnerabilities surfaced by our vending machine become detection checks in the Intruder platform, so your next scan finds and reports them.

Get started on Intruder for free.

Author: 

Sam Pizzey, Security Engineer, Intruder

Sam Pizzey is a Security Engineer at Intruder. Previously a pentester a little too obsessed with reverse engineering, currently focused on ways to detect application vulnerabilities remotely at scale.

Sponsored and written by Intruder.