Skip to main content

PHP Developers Wanted a Patch. Hackers Wanted a PoC. Nobody Slept

Updated 5 min readMarkdown
PHP Developers Wanted a Patch. Hackers Wanted a PoC. Nobody Slept

Two critical PHP vulnerabilities, one sleepless night, and AI agents making the race a lot more interesting.

October 20, 2026.

Imagine being a PHP developer or a sysadmin running production applications. You hear that two critical remote code execution vulnerabilities are about to be patched. The technical details aren't fully public yet, but the severity is enough to make you nervous.

Now imagine being on the other side, investigating vulnerabilities. You hear the exact same news, but your first thought is different.

Developers: "When is the patch coming?"

Hackers: "Can we find the bug before the patch?"

Same announcement. Two completely different deadlines.

And somewhere in between, AI agents are burning through tokens trying to figure out what everyone is looking for.

So, what happened with PHP2Shell?

On October 20, the PHP security team announced an emergency release addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.

Both received a critical CVSS v4.0 score of 9.2.

These weren't typical application-level issues caused by missing input validation or a badly written authentication check. The vulnerabilities existed in the PHP runtime itself.

The underlying problem involved memory handling. Under certain conditions, fatal errors during request processing could interrupt normal cleanup, leaving dangling pointers and creating use-after-free conditions.

For developers familiar with memory safety, that's already a worrying combination.

The researchers demonstrated pre-authentication remote code execution against applications including WordPress, Drupal, Laravel, and Symfony, with some paths affecting even simple PHP scripts.

The official fixes arrived on October 21, following an accelerated disclosure caused by an early public leak.

But the period before that release is what caught my attention.

The interesting part wasn't just the vulnerability

I recently watched a security researcher's walkthrough of an attempt to independently rediscover PHP2Shell before the patch.

What interested me wasn't simply whether an exploit worked. It was the investigation process.

The researcher started with limited information from a leaked demonstration, examined PHP version history, looked through source code, and used Codex agents to investigate possible memory-corruption paths.

And it wasn't as simple as asking:

"Hey Codex, find me a PHP zero-day."

The agents found unrelated issues, followed incorrect assumptions, ran thousands of tests, and even investigated publicly circulating PoCs that turned out to be misleading.

Eventually, the investigation reproduced a real use-after-free condition using AddressSanitizer. But turning that finding into a reliable exploit was another challenge. The initial PoC depended on reading memory addresses from the test environment rather than obtaining them through a practical information leak.

That distinction matters. Finding a crash, proving a vulnerability, and building a reliable RCE exploit are not the same thing.

And that's where the story gets interesting.

Zero-days in the agent era

This is the part that makes me think beyond PHP2Shell.

A few years ago, developing a working exploit for a complex memory-corruption vulnerability usually demanded substantial manual research, specialized knowledge, and time. Public PoCs often appeared after patches or detailed technical disclosures, although that was never guaranteed.

Today, the workflow is changing.

A researcher might have only a short demonstration, a version range, a few technical hints, or even a rumor. With coding agents, they can start exploring source history, comparing commits, generating hypotheses, building test environments, and writing scripts to reproduce suspicious behavior.

Work that previously required days of manual investigation can sometimes be compressed significantly.

The scary part isn't that AI can magically discover every zero-day. It can't. The scary part is how much investigation can now begin with so little information.

Of course, agents still hallucinate, misunderstand code, produce false positives, and encounter safety guardrails. Memory-corruption exploitation still requires real expertise, especially when dealing with ASLR, heap behavior, information leaks, and exploit reliability.

But those limitations don't eliminate the advantage.

An experienced researcher using agents can explore more possibilities and discard incorrect theories faster. And malicious actors can benefit from some of those same capabilities.

For defenders, that potentially shrinks the time between an early vulnerability disclosure and the appearance of useful exploit techniques.

PHP2Shell is a pretty good reminder of why that matters.

The AI irony

One detail from the walkthrough made me smile.

While some people were using AI to investigate the real vulnerability, others were circulating AI-generated PoCs that didn't actually match it.

So agents were helping researchers find bugs while also producing convincing-looking nonsense that other researchers had to waste time disproving.

Peak 2026 security research.

But the original https://calif.io/php2shell/ research also demonstrated something important: deep knowledge of the target still matters.

The researchers connected historical PHP memory-management issues, old bug reports, and modern agent-assisted analysis to find exploitable paths that earlier investigations had missed.

AI accelerated parts of that process. It didn't replace understanding the problem.

My takeaway

I've always found this side of software engineering fascinating.

We spend so much time learning how to build reliable systems, but investigating how those systems fail teaches us something different.

A feature that looks completely harmless at the application level can behave very differently when you understand the runtime, memory lifecycle, and underlying implementation.

And with AI agents entering vulnerability research, I'm increasingly curious about how offensive and defensive security will evolve.

One thing seems clear: the patch window is becoming a much more competitive race.

Developers want the vulnerability fixed before someone exploits it.

Researchers want to understand it before the patch reveals the answer.

And AI agents? They're somewhere in the middle, occasionally finding something useful, occasionally inventing an entirely new problem.

Nobody slept. At least the tokens were productive. Sometimes.


References

About the author

  • Spent years learning how systems fail. Now I build ones that don't

No comments yet. Be the first to comment.