In November 2025, Anthropic disclosed that a threat actor had used Claude to orchestrate a cyber espionage campaign targeting roughly 30 organizations. The AI performed 80-90% of the work, with only four to six human decision points. Everything else was automated.

In February 2026, Anthropic's Frontier Red Team published research showing Claude had discovered over 500 high-severity zero-day vulnerabilities in widely used open-source projects. Bugs that had survived decades of expert review and millions of CPU hours of fuzzing, found by reading code and reasoning about it.

In March 2026, Anthropic documented Claude writing a working proof-of-concept for a Firefox JIT bug. While it required a disabled sandbox and some iterations, it marked a major milestone: the first time a model wrote a successful browser exploit with minimal hand-holding.

This isn't theoretical anymore. AI is already finding vulnerabilities faster than most teams can triage them, and building proof-of-concept exploits that would have taken experienced researchers days or weeks.

To build the best defense, we often have to understand the real capability and not one in a controlled sandbox. On a real vulnerability, with real defenses in front of it, in a realistic environment.

This post documents what we found, including two novel OWASP Core Rule Set bypasses we responsibly disclosed, before being asked to open a Github Issue.

We were researching a straightforward question: how quickly can AI develop a working proof-of-concept for a known vulnerability it has no prior context on?

CVE-2026-25632 was a good test case. It's a critical deserialization vulnerability in EPyT-Flow, a water network simulation toolkit used in OT environments. CVSS 10.0. The advisory described the vulnerability pattern but no public proof-of-concept existed.

EPyT-Flow is not the kind of project that shows up in AI training data at scale. There are no writeups, no public PoCs, and no Stack Overflow threads about its internals. To develop an exploit, AI had to reason through the source code from first principles rather than pattern matching against memorized examples.

Using Claude, we set up a research environment: a vulnerable Docker lab running EPyT-Flow 0.16.0 behind a ModSecurity WAF. Then we gave Claude the source and asked it to develop a proof-of-concept.

For the full technical breakdown of CVE-2026-25632 and all 79 gadgets we mapped across the Python standard library, read the disclosure post here.

Claude read the deserialization logic, identified that the __type__ field lets an attacker control which Python callable gets invoked, recognized that subprocess.run accepts keyword arguments, and produced a working payload:

{"__type__": ["subprocess", "run"], "args": ["id"], "capture_output": true}

uid=0(root) gid=0(root) groups=0(root)

We got full remote code execution on the first attempt, without any iteration.

Before AI, an experienced security researcher would read the advisory, pull the source code, trace the deserialization path, identify the exploitable callable, and write the payload. Depending on the complexity of the codebase and the researcher's familiarity with the framework, that process takes hours to days. For a less experienced attacker working without prior deserialization research, it could take significantly longer.

Claude did it in seconds.

The simple PoC isn't the interesting part. The vulnerability is straightforward enough that a skilled engineer would get there too. What is interesting is how much faster this process was with AI.

We asked Claude to design a scanner that could enumerate every Python stdlib callable exploitable through the same __type__ primitive. Not just subprocess.run, but everything.

Claude designed the classification heuristics and helped implement the scanner. 51 modules, 1,156 callables, a four-phase pipeline that classified each one by what an attacker could actually achieve with it.

The result: 79 gadgets across seven categories. 12 remote code execution paths, 25 server-side request forgery paths, 18 file write primitives, 10 file read paths, and more.

Manually enumerating 1,156 callables with the same classification rigor would take a researcher days. Claude designed the approach in minutes. The whole scanner was running within the hour.

This is the part that matters for defenders. The advisory mentioned one gadget. There are 79. With AI, the full surface gets mapped, the paths that evade detection get found, and the one your defenses don't cover gets selected. That work used to take days. Now it takes an hour.

Read more about the full attack surface and all 79 gadgets in the CVE-2026-25632 disclosure.

The PoC came too easily to tell us much about AI's real capability. So we added a real defensive layer: ModSecurity 3.0.14 + OWASP CRS v4.24.0 at Paranoia Level 2, plus four custom rules specifically targeting the deserialization pattern.

The naive payload hit a 403 and was blocked immediately.

What happened next took an afternoon, and led to two security findings we hadn't expected. Before AI, this kind of systematic WAF bypass analysis, understanding the regex internals of multiple rule sets, identifying the inspection points, finding the gaps, would be a multi-day effort requiring deep familiarity with ModSecurity's processing pipeline.

Claude approached it methodically. It identified that the custom rules inspect raw request bytes while CRS rules inspect decoded values. It recognized that JSON Unicode escapes (\uXXXX) are semantically identical to literal characters for the application but invisible to raw-byte regex inspection. That insight alone bypassed all four custom rules.

For the CRS rules, Claude extracted the actual regex patterns from the running WAF container, tested candidates programmatically, and found uconv, a legitimate Unicode conversion utility that reads files just like cat but was absent from the CRS command blocklist. It then identified a regex blind spot in CRS rule 932200's glob detection by analyzing the lazy quantifier's behavior, discovering that glob characters at the start of a filename evade detection entirely.

The result was two evasion layers that bypassed nine rules total, with data exfiltrated through a production-grade WAF configuration.

Neither of these CRS gaps had been publicly documented before. We reported both to the OWASP CRS project, the maintainers confirmed them, and we waited for the fix to be merged before publishing this post. What started as research into AI speed produced genuine security findings that improved a widely used open-source project.

The bypass chain wasn't built by brute-forcing payloads against the WAF. It was built by reading, understanding, and reasoning about the defensive logic. That's the shift. AI doesn't just try faster. It thinks through the problem.

The speed at which AI can generate a working proof-of-concept is the story here, not any single technique we used.

An experienced security engineer was still behind this research. AI doesn't replace the judgment calls: scoping the work, designing the test environment, validating results, making disclosure decisions. But it compresses the mechanical work (the code reading, the enumeration, the regex analysis, the payload iteration) from days into hours.

Luckily public models have safety guardrails. In this case, the research was conducted responsibly within appropriate bounds, and the model cooperated because the work was clearly framed as security research. But Anthropic's own disclosure showed that even public models can be manipulated through task decomposition into performing offensive operations. Attackers broke the work into small, innocent-looking subtasks so the model never saw the full picture. And open-weights models don't have guardrails at all.

The result was a capability that used to require deep specialization, years of reading disassembly, writing exploits, understanding defensive architectures, is now accessible to a much wider range of attackers. Not because AI replaces expertise, but because it compresses the learning curve. Someone who couldn't write a deserialization exploit last year can have AI walk them through it this year. Someone who couldn't analyze WAF regex internals can have AI extract the patterns, test candidates, and find the gaps.

The barrier to entry for creating critical attacks just dropped significantly, and it keeps dropping with every improvement to these models. Most LLM providers try to prevent this kind of use, but open models have no such restrictions, and even guarded models could be circumvented through careful prompting.

We don't like to spread fear, but the uncomfortable truth is if you're not using AI to find these problems, you're bringing a manual process to an automated fight.

The same capabilities that let AI build a proof-of-concept in seconds can triage your vulnerability backlog in minutes. The same reasoning that found the WAF bypass can audit your WAF rules before an attacker does. The same speed that mapped 79 gadgets from a single advisory can scan your deserialization endpoints and flag the missing allowlist before it ships.

AI can rank unpatched CVEs by exploitability against your specific stack in the time it takes a person to read the first advisory. It can review code and identify patterns like the __type__ dispatch, the kind that are trivially exploitable but easy to miss in a code review. It can write detection rules for evasion techniques that aren't in any public database yet, because it reasons about the technique rather than pattern-matching against known signatures.

But most security teams aren't doing any of this yet. Some tools exist, many are being built, but it's a balance as always to adopt.

Right now, the balance seems to favor offense. Attackers are already iterating with AI while defenders are often forced to work manually, and the longer that gap stays open, the wider it gets.

The question isn't whether AI changes the speed of vulnerability research. Anthropic answered that when they found 500 zero-days in widely used projects. We confirmed it when a single CVE with no public PoC turned into 79 gadgets and two WAF bypasses in an afternoon. The question is whether defenders adopt these same capabilities before the gap becomes too wide.

This is exactly the challenge we set out to solve at Maze. We build AI agents that investigate, triage, and remediate cloud vulnerabilities because we believe the only way to keep up with AI-accelerated offense is AI-accelerated defense. The same reasoning capabilities that make AI effective at finding and exploiting vulnerabilities are what make it effective at determining whether those vulnerabilities are actually exploitable in your specific environment, and helping you fix the ones that are.

Read more about CVE-2026-25632, including the full attack surface we discovered, disclosed, and remediation guidance, in the disclosure post here.