Two Critical PHP Vulnerabilities, and What AI Has to Do With Them

CVE-2026–109618 and CVE-2026–109619 ("PHP2Shell") are a reminder that the runtime is part of your attack surface

Recently, I was going through some cybersecurity updates, and one disclosure caught my attention: two critical vulnerabilities in PHP, nicknamed PHP2Shell, both rated 9.2 out of 10 under CVSS v4.0.

When I first saw this, I had a few questions:

Why are these vulnerabilities considered so critical?
What exactly is happening inside PHP?
What does this mean for organizations running PHP-based applications?

So I spent some time on the technical details. Along the way, I found something even more interesting: the role AI played in uncovering them. Here's what I understood.

Where is the weakness: the application or the runtime?

PHP powers a huge share of web applications and content platforms. The first thing I wanted to clarify was whether these issues sit in application code or in PHP itself. The difference matters.

When a user sends an HTTP request, the web server receives it and PHP processes it before returning a response. Along the way, PHP handles memory allocation, object initialisation and resource cleanup internally.

Both vulnerabilities are in how PHP manages these internal operations. The weakness isn't in the business logic your team wrote. It's in the runtime underneath it. Every PHP installation that serves web requests is in scope, whether it runs under PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or FrankenPHP. In the worst case, Apache with mod_php, an attack can succeed before any of the application's own code has run.

CVE-2026–109618: When cleanup goes wrong after an out-of-memory failure

Normally, when an application runs out of memory, it crashes, returns an error or stops processing. This case is subtler.

Imagine PHP is building an internal data structure. Memory is allocated, fields are initialised, and then an allocation fails partway through. PHP now has to clean up whatever it already allocated.

The problem appears when the cleanup routine assumes the structure was fully initialised, even though the work stopped halfway. In the researchers' write-up, the concrete case was a PHP hash table that counted a new entry as "live" before that entry was fully set up. If memory ran out at exactly that moment, the cleanup code later walked over the half-built entry and trusted it.

That kind of memory corruption can be exploited for remote code execution (RCE). And RCE doesn't just mean a crash. It means an attacker may be able to make your server run code of their choosing.

CVE-2026–109619: Use-after-free

PHP's advisory calls this one "RCE via stale global state" and classifies it as a use-after-free.

The concept is simple. Software allocates memory, uses it, and releases it when it's done. After release, it must not keep accessing that memory through the old reference.

Now consider a PHP worker that handles many requests, one after another. Some internal state is kept by the worker but points to memory owned by one specific request. When that request ends, its memory is released. If the state isn't reset first (for example, because a fatal error interrupted the normal cleanup), the worker is left holding a stale reference.

When the same worker picks up the next request, some operations run before normal initialisation has had a chance to reset that state. They act on memory that no longer belongs to them. With a carefully crafted memory layout, that can lead to full remote code execution.

Two different bugs, one common lesson

The root causes are different. One involves unsafe handling when a memory allocation fails. The other involves accessing memory after it has been released. But both show how flaws in a runtime's internal memory management can create serious security exposure.

Why 9.2 and not 10?

CVSS looks at how an attacker reaches the system, whether authentication or user interaction is needed, what conditions exploitation requires, and what impact a successful attack would have.

Here, the potential impact touches all three parts of the CIA triad:

Confidentiality: access to sensitive information
Integrity: changed data or unauthorized operations
Availability: disrupted services

So why not a perfect 10? A high potential impact doesn't automatically produce the maximum score. For CVE-2026–109619, PHP's advisory spells it out: the flaw is reachable over the network with no privileges or user interaction, and the impact is high across the board. But Attack Complexity is rated High and Attack Requirements are Present, because the right conditions have to line up. That is what keeps the score at 9.2, still firmly Critical.

This is not just theoretical

Details of the vulnerabilities leaked on social media on October 20, ahead of the planned disclosure. PHP pushed out an emergency release the next day. According to watchTowr, exploitation has been observed in the wild since October 21 through its honeypot network. As of October 22, CISA had not yet added either CVE to its Known Exploited Vulnerabilities catalog.

The part I found most interesting: AI

While reading about these vulnerabilities, I noticed that AI-assisted research played a central role.

The bugs were found by researchers at Calif, working with OpenAI and Wiz as part of OpenAI's "Patch the Planet" initiative. In their write-up, the researcher describes using an LLM as an audit companion. It helped review PHP's memory allocator and shutdown code, spot a risky ordering of operations, and trace how an ordinary HTTP request could reach it. The team then had the model generalize that first finding into a reusable pattern, which led to further variants.

Two details stood out to me.

First, the researcher says no special harness or unreleased models were used for the initial discovery. These were generally available tools.

Second, human expertise still mattered. The researcher deliberately steered the AI toward a class of PHP memory-limit bugs going back to 2004. In fact, the out-of-memory issue had surfaced before: it was reported in 2020, and a related issue was rediscovered in a 2024 security audit. But exploitation wasn't proven, so it wasn't fixed as a security issue. According to the researchers, the earliest affected code path goes back to PHP 5.4.0.

Memory-related vulnerabilities are hard to analyze. They involve complicated execution paths, unusual runtime conditions and behavior that's difficult to reproduce. Traditionally, that meant a lot of manual effort. AI can speed up parts of that work.

AI didn't introduce these weaknesses into PHP. They were already there. What AI changes is how fast complex weaknesses get discovered, analyzed and turned into working exploits.

This goes beyond PHP. If researchers can investigate faster with AI, attackers can try the same. And in this case, exploitation was reported within about a day of the details leaking. Whether or not attackers used AI here, that is the kind of window teams now have to plan for.

What organizations should do now

The PHP project released security updates on October 21, 2026. Fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

Inventory every place PHP runs: servers, containers, base images and managed hosting. Include older branches. PHP 8.1 and older get no official release (look for distribution or LTS vendor packages), and PHP 7.3 and older have no fix at all.
Prioritize internet-facing systems, especially anything running PHP as an Apache module.
Restart every PHP worker after updating so the fix actually takes effect.
Don't rely on configuration workarounds. PHP states that no configuration change fully mitigates these vulnerabilities. The advisories list partial measures only for systems that can't be patched immediately.

There's one more consideration. We often focus on the applications themselves: code, libraries, plugins and configurations. All of that matters. But this disclosure is a reminder that the runtime and supporting layers need the same visibility. Even when your application code is secure, a vulnerability in the runtime underneath can still expose you.

My biggest takeaway

For me, this isn't just about two PHP bugs with a 9.2 score. It's about how vulnerability management is changing.

A weakness can sit inside a component for years, as this one did. But once someone understands it and builds a practical exploitation technique, the risk can change very quickly. AI may speed that process up.

So the question is no longer only "Do we know about critical vulnerabilities?" It's also "Can we identify our exposure, assess the business impact and deploy fixes fast enough?"

The vulnerability may have existed for a long time. But the speed at which it becomes a practical threat may be changing.

I'd be interested to hear your thoughts. Are our vulnerability management and patching processes ready for the speed of AI-assisted security research?

Sources:

Contents