AI Cybersecurity in Action
I’ve seen a lot of AI vulnerability research. Most of it sounds like a TED Talk: "Imagine if models could find bugs!" But here’s the thing — the future isn’t hypothetical anymore. It’s running in Docker containers, churning out SQL injections, and getting plugins yanked from the WordPress repository. I saw it. I read the logs. And I’m still unsettled.
Intruder’s team didn’t build a demo. They built a vending machine.
You drop in a codebase. You get back a zero-day. No coffee breaks. No peer reviews. Just a silent, relentless pipeline that doesn’t care if you’ve already patched every known flaw. It doesn’t care if you think you’ve "done enough." It just finds what’s left.
And it found one in a plugin with 300,000 installs.
Why AI Fails at Codebases — And How Slicing Fixes It
Here’s the dirty secret: LLMs are terrible at reading entire codebases.
I’ve watched models choke on 10,000-line files. They’ll spot a typo in a comment, miss a SQL injection buried in a nested callback, and then spend half their context window explaining why the code is "probably secure." Why? Because context dilution isn’t a bug — it’s the default.
You give an LLM a whole WordPress plugin and say, "Find me a vulnerability," and it’s like asking someone to find a needle in a haystack… while they’re also juggling three other haystacks.
The fix isn’t more context. It’s less.
Intruder’s team used program slicing — a technique from 1980s static analysis — to surgically isolate the exact code paths that handle user input. Joern, their code scanner, doesn’t scan everything. It finds every REST endpoint, every AJAX hook, every nopriv function. Then it builds a slice: just the function, the functions it calls, and the functions those call. Nothing else.
It’s like using a laser instead of a flamethrower.
The model doesn’t see 12,000 lines of WordPress boilerplate. It sees 87 lines of code where user input flows into a database query. That’s enough. That’s all it needs.
The Pipeline: From Code to Exploit, No Humans Allowed
This isn’t a two-step process. It’s a factory.
Step one: Joern scans the top 200 WordPress plugins — the same ones everyone’s already scanned. The low-hanging fruit. The ones you’d think are clean.
Step two: Slicing. Every input point gets sliced. Every taint flow gets tracked. If a value goes through a known sanitizer? It’s dropped. No point wasting tokens on it.
Step three: Sonnet, the triage model. It looks at each slice and says: "Is this even interesting?" If it’s just a public endpoint that echoes back a user ID? Skip. If it’s a POST request that touches a database without validation? Keep.
Step four: Opus. The heavy hitter. It gets the slice, the context, and the question: "Can this be exploited?" Not "is this a vulnerability?" — "can it be turned into an exploit?" It doesn’t just read the code. It simulates the attack in its head.
Step five: The exploit agent. It writes the PoC. Not a theoretical description. Actual, runnable code. And then — here’s the kicker — it spins up a Docker container with the exact version of the plugin, installs WooCommerce, and runs the exploit against it. Live. In a sandbox. To confirm it works.
No humans. No "I think this might work." Just code, containers, and confirmation.
The First Vending: CVE-2026-3985 in Creative Mail
The first thing the machine spat out? CVE-2026-3985.
Blind SQL injection. In Creative Mail. A plugin with 300,000+ installs. And it required WooCommerce.
That’s the beauty of it.
Most scanners look for standalone flaws. This one found a combination. A flaw that only exists when two plugins are together. A vulnerability that’s invisible if you scan either one alone.
The exploit chain? Three steps. One to trigger the injection, one to extract the admin hash, one to escalate to full database access. All automated. All generated in under 40 seconds.
And here’s what’s wild: Dmitrii Ignatyev at CleanTalk found the same thing — independently. That’s not coincidence. That’s inevitability.
When the same bug gets found by two different teams, one human, one AI, you’re not looking at a fluke. You’re looking at a new normal.
The plugin’s been pulled. The WordPress repo doesn’t play around. But the damage? It’s already done. Every site running Creative Mail + WooCommerce since January is compromised. And nobody knew.
The Real Impact: AI Doesn’t Just Find Bugs — It Changes the Rules
This isn’t about one plugin. It’s about the new math of security.
Before: You had 30 days to patch after a CVE drops.
Now: You have 30 minutes. Because the AI that found it? It’s already scanning your competitors. And your suppliers. And your dependencies.
Intruder’s team didn’t just find a bug. They proved that AI can outpace human researchers in the most competitive sandbox on earth: WordPress plugins. And if it can do that here — where every line of code has been reviewed a thousand times — what’s it going to do in a custom SaaS app? A banking API? A medical device firmware?
The real danger isn’t that AI finds bugs.
It’s that attackers are already using the same tools.
We’re not talking about script kiddies. We’re talking about organized threat actors with budgets, Docker clusters, and a pipeline that runs every night. They’re not waiting for CVEs. They’re building their own vending machines.
And Intruder? They’re feeding their findings back into their own platform. So when you run a scan tomorrow? It’ll catch what their AI found today.
That’s defensive AI. That’s the only way forward.
The Future Is Autonomous — And It’s Already Here
I used to think AI in security was about automation. Now I know it’s about autonomy.
This isn’t a tool. It’s an agent. It doesn’t need you to ask. It doesn’t need you to review. It just does.
And it’s not stopping.
The next vulnerability? It’s already being sliced. The next exploit? Already being tested in a container.
The question isn’t whether you’ll adopt this.
It’s whether you’ll be ready when it finds your flaw — and you didn’t even know you had one.
