PHP2Shell is not the news. The news is that we are still waiting for the patch

By: R&D+i Team – BASE4 Security

In brief: In this article we analyze PHP2Shell and why, at a time when AI is accelerating vulnerability exploitation, patching fast is no longer enough: the key is to limit the impact and design an architecture that is ready to assume compromise.

Patching is necessary. Limiting the impact is what makes the difference.

For the past two days, everyone has been talking about PHP2Shell. There are emergency bulletins, hastily published WAF rules, threads full of screenshots and the familiar list of recommendations: update now, review your inventory, monitor. All of that is correct. And yet the conversation keeps circling around the least interesting part of the incident.

PHP2Shell is not an anomaly. It confirms something we have been seeing for months: the time between a vulnerability becoming known and being exploited has shrunk to hours, and much of that acceleration is driven by artificial intelligence. Against that backdrop, the typical response (patch faster and put a ZTNA in front of everything) is a strategy that has already lost.

This article does not aim to add yet another alert. It asks a different question: what happens in our architecture when the attacker is already executing code on the server? If the answer is uncomfortable, the problem is not PHP.

What PHP2Shell is, in brief

PHP2Shell groups two critical vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619, both scored 9.2 under CVSS v4.0. They are not in WordPress, Drupal or a Composer library. They are in the runtime, and they affect every version since PHP 5.4.

The root cause is a design decision made decades ago. PHP uses longjmp() to abort on fatal errors, including memory exhaustion. If that happens at the wrong moment, the request state is left half-built or holding references to memory that has already been freed, and the subsequent cleanup treats it as valid.

• CVE-2026-109618: an out-of-memory condition interrupts request parsing (for example, a multipart request that fills $_POST and $_FILES) and leaves structures uninitialized.
• CVE-2026-109619: a fatal error leaves pointers to memory that is freed at the end of the request. It is triggered through the session upload progress mechanism, on any POST endpoint and before any application code runs.

The result is unauthenticated remote code execution with the privileges of the web worker, plus a memory leak path that can expose passwords, tokens and keys from other requests. Wiz has already demonstrated it against WordPress, Drupal and Joomla. An estimated two million servers are exposed running vulnerable versions.

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no official patch for PHP 8.1 and earlier: those branches are unsupported.

AI has compressed the exploitation window

The PHP2Shell timeline says more than any technical analysis. On October 20, the details leaked, one day before coordinated disclosure and with no patches available. Cloudflare reported that it was already seeing attack traffic against its customers during that window. The patch was released on the 21st at 14:00 UTC. By then, the attacker’s clock had been running for hours.

Among those who reported the flaws is an AI lab, alongside traditional research firms. This is not an anecdotal detail. Current models are finding memory bugs in decades-old C code, reviewed by thousands of people, that nobody had spotted. A finding like this coming from AI is a sign of the new pace.

The uncomfortable part is that this capability is symmetric. The same kind of tool that helps a researcher find a use-after-free helps an attacker to:

1. Read a terse advisory, or a patch diff, and work out the exact bug.
2. Write and debug a working exploit in hours instead of weeks.
3. Adapt it to hundreds of stack variants (Apache with mod_php, PHP-FPM, different versions and memory configurations).
4. Scan the Internet, prioritize targets and automate post-exploitation.

A few years ago, there was a margin of days or weeks between the publication of a critical CVE and its mass exploitation. That margin was the cushion on which almost all of our vulnerability management processes were designed. That cushion no longer exists, and PHP2Shell proves it with a concrete case: exploitation happened before the patch existed.

You do not need to be alarmist to accept this. You only need to look at the incident’s own timeline.

Why “patch faster” is a losing race

The popular reading of PHP2Shell is that we need to patch faster. Nobody disputes that patching is necessary. What we dispute is that it is enough as a strategy.

Think of a real mid-sized organization. It runs PHP on its corporate website, its customer portal, two or three legacy internal systems, the admin panel of some network appliance, its ticketing software and a couple of servers nobody remembers setting up. Each one has its own owner, its own maintenance window and its own risk of breaking when updated.

In that context, “patch within 24 hours” is not an operational goal. It is wishful thinking. And even if it is met, the attacker has already had their window. On top of that, there are obstacles that speed does not solve:

• Unsupported branches. Anything running PHP 8.1 or earlier has no official patch. The only options are relying on the distribution’s backport or migrating to a new version, which cannot be done in a day.
• Embedded PHP. Appliances, NAS devices, firewalls, camera systems and hosting panels ship their own PHP. The customer does not control it and depends on the vendor’s schedule.
• Incomplete inventory. You cannot patch what you do not know exists. External scanners detect what is exposed; internal systems are usually left out.
• The patch does not undo the compromise. If a server was exploited during the earlier window, updating it closes the door but does not remove whoever is already inside.

The “exposure window” mental model assumes there is a reasonable period between the warning and the attack. With AI on the offensive side, that period tends toward zero. Building defense on patching speed means building it on an assumption that no longer holds.

The Zero Trust we were sold does not stop this

When Zero Trust comes up, most people think of the same thing: replacing the VPN with a ZTNA, requiring MFA, validating device posture and granting access to applications based on identity. It is a real improvement over the perimeter model. It is also a trimmed-down version of the concept.

PHP2Shell exposes that gap clearly. The vulnerability:

• Is exploited against a public service, which by definition accepts traffic from anyone.
• Is triggered before any login, during request parsing.
• Requires no credentials, no device and no identity.

For this attack, the most sophisticated ZTNA on the market is irrelevant. There is no identity to verify. The attacker does not get in “through” access control; they get in through the service that access control deliberately leaves exposed.

The problem is that, across much of the market, Zero Trust has become a product category rather than an architectural principle. You buy a ZTNA, tick the roadmap item and declare the organization “Zero Trust”. Meanwhile, the web server keeps running with broad permissions, unrestricted outbound Internet access, long-lived database credentials in a configuration file, and in a segment that reaches half the data center.

That is not Zero Trust. It is implicit trust in workloads, with a good front door for users.

Full Zero Trust: assume the workload is compromised

The original Zero Trust principle is simple: nothing is trusted for being “inside”, and the breach is assumed to have already happened. Applied seriously, that means designing every exposed service as if an attacker were already executing code on it. With PHP2Shell, that hypothesis is no longer theoretical.

The design question changes. It is not “how do I keep them out?” but “what can someone already executing code as www-data do?”. Full Zero Trust answers with concrete controls:

None of these controls is new, and none depends on knowing which vulnerability will appear tomorrow. That is their main strength. They work just as well against PHP2Shell, the next deserialization bug or a malicious plugin.

The usual argument against them is operational cost. It is real. But it is worth comparing with the alternative: depending on winning, every single time, a race against attackers who now have automation on their side. A well-implemented egress control is a project with an end date. Patching against the clock is an effort that never ends.

Detect post-exploitation, not the exploit

The other half of the typical response is signature-based detection: WAF rules, IDS rules, exploit IOCs. They help, but they arrive behind the attacker. Every exploit variant, every change in encoding or multipart structure, forces a rule update. With AI generating variants, that is also an uneven race.

There is a more robust approach: stop hunting for the exploit and look for what the attacker has to do next. Regardless of how they got in, they need to move to get value, and that movement leaves traces that do not depend on the CVE:

• A PHP process spawning sh, bash, curl, wget or an interpreter the application never uses.
• A web server opening an outbound connection to an IP that is not part of its normal profile.
• Reads of configuration files, SSH keys or environment variables outside the usual pattern.
• Internal scanning or authentication attempts against other systems from the web segment.

These are high-fidelity signals because a healthy PHP server almost never produces them. They work today against PHP2Shell and will work tomorrow against whatever comes next.

The message is simple: the exploit changes with every CVE; what the attacker does afterwards changes far less. It pays to invest in detecting the latter.

What to do on Monday

None of the above replaces the immediate urgency. Action is needed on two timelines.

This week (tactical)

1. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. For unsupported branches, apply the distribution backport or isolate the service until you migrate.
2. Inventory PHP beyond the known web servers: appliances, panels, legacy systems and containers.
3. Enable your provider’s WAF rules as a temporary measure, knowing that is exactly what they are: temporary.
4. Look for evidence of compromise since October 20: unexpected child processes of the web server, anomalous outbound connections, new files in web directories.
5. Rotate credentials and tokens accessible from exposed servers that were vulnerable during the window.

This quarter (structural)

1. Review every exposed service with the question: “if the attacker executes code here, what can they reach?”. Document the answer.
2. Implement egress control in the segments that host public services.
3. Move secrets out of configuration files and into a manager with short-lived credentials.
4. Segment east-west traffic at the workload level, not just the VLAN level.
5. Deploy behavioral detections (processes, network, file access) and decoys in exposed environments.
6. Measure the program by time to detection and scope of compromise, not only by the percentage of patches applied.

Closing

In a few weeks, PHP2Shell will be just another chapter in annual reports. Another bug will arrive with another name, another logo and, most likely, another AI-assisted discovery. The question is whether, by then, we will still be measuring our security by how quickly we react to the headline.

The industry tends to turn every incident into an argument for the next product. This time it is worth resisting that temptation and doing something less flashy: accepting that the exposed service will be compromised at some point, and designing so that it matters little. That is real Zero Trust. Not a ZTNA license, but an architecture in which gaining initial access gives the attacker almost nothing.

What defines the impact of the next vulnerability is not how long it takes us to patch. It is how much the attacker can do in the hours before we do.

Sources

• Cloudflare: PHP2Shell protections
• Armis: how to find, prioritize and patch
• Huntress: PHP2Shell Rapid Response
• OX Security: analysis of CVE-2026-109618 and CVE-2026-109619
• Abstract Security: PHP2Shell flash report
• The Hacker News: PHP2Shell