PHP2Shell: How an AI-Found Flaw Moved From Discovery to Exploitation, and What It Means for Your Appliances

Last week I argued that the bottleneck in cybersecurity is no longer finding bugs. It is everything that happens after discovery. Within days, PHP2Shell turned that argument into a live case study.

PHP2Shell is the name given to two critical vulnerabilities in the PHP runtime itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 [1][2]. They allow unauthenticated remote code execution, and because the flaws sit in PHP's core memory handling, they can be triggered before any application code runs [3]. Wiz, which led the research, says nearly every PHP release from the last decade carries at least one of the issues [1].

How the Flaws Were Found

According to Wiz, its researchers used frontier AI models, including Gemini 4 Argon and GPT-5.6 Sol alongside its own Wiz Atlas platform, to find the bugs, build a working exploit, write detections and validate the patch [1]. Wiz credits the models with a large share of the work, from discovery through exploit development [1].

In short, the two issues are:

• CVE-2026-109618: an out-of-memory condition, for example during a large multipart upload, leaves request data partly initialized. Cleanup code then treats that invalid data as valid [2][3]. Wiz also describes a memory disclosure path that can leak data from other requests, such as passwords and tokens [1].
• CVE-2026-109619: request-owned state survives after its memory is freed, and a later request on the same worker can use it [2][3].

Wiz demonstrated unauthenticated code execution against default container images of WordPress, Drupal and Joomla [1]. Its headline figure of "70% of the Internet" refers to PHP's share of websites, not a measured count of vulnerable servers, so treat it as an indication of reach rather than a census [1].

The Timeline

Two things stand out. First, 58 days passed between the report to PHP and the fixed releases. That is not slow for a fix that touches the core of a language runtime used by millions of sites, and it is roughly what responsible coordination looks like. Second, the coordinated window collapsed in the final 24 hours. Once details leaked, the gap between public knowledge and attack attempts was measured in hours.

That is exactly the gap compensating controls are meant to cover.

A Third CVE, Two Days Later

On October 23, PHP disclosed CVE-2026-115560, another remote code execution path [2]. It is not a bypass of the October 21 fixes. It is a separate bug, and PHP describes it as an unlikely vector that requires an unusual configuration [2]:

• The application sets session.serialize_handler to php_binary or php_serialize, then switches it to php at runtime with ini_set() before calling session_start().
• Session upload progress is still enabled.

Until the next regular bugfix release, PHP's official guidance is to disable session upload progress in php.ini, the FPM pool or the server configuration, and then restart every PHP worker [2]:

session.upload_progress.enabled=0

PHP notes that the setting must apply before request parsing, so ini_set() and FPM .user.ini files are not a substitute [2]. Teams that already applied this setting as a mitigation for CVE-2026-109619 do not need to do anything else [2].

The Real Exposure: PHP Inside Products You Do Not Patch Yourself

Patching PHP on a web server you own is a known task. The harder problem is PHP embedded inside commercial products: management consoles, appliances and SaaS back ends. For those, you depend on the vendor to rebuild, test and ship a fix. This is the "upstream patch is not an installed fix" problem in its clearest form.

VMware Cloud Foundation, vDefend and Avi

For the VMware portfolio, the position is clear:

• VMware Cloud Foundation: VCF components do not use PHP and are not affected [7].
• vDefend: all components, including the Distributed Firewall, Gateway Firewall, Advanced Threat Prevention and the Security Services Platform, do not use PHP and are not affected [8].
• Avi Load Balancer: not affected, with published WAF mitigations for customers protecting PHP applications behind Avi [3][9].

Broadcom maintains a central PHP2Shell page with its latest status and guidance [18].

For VCF customers, that means the platform itself is not part of the problem. The exposure is in the PHP workloads running on it, which is where the next sections focus.

Other Security and Network Vendors

As of October 23, the major security vendors had published the following positions. These change daily, so check each advisory directly before acting.

The pattern matters more than any single row. Most vendors moved quickly to ship detection signatures, because that is the fastest thing they can do. Fixes for their own embedded PHP take longer, because each product has its own build, test and release cycle. Palo Alto's schedule shows this clearly: the PHP fix shipped on October 21, and the PAN-OS fixes follow five to nine days later [10].

If a product's management interface is reachable from the internet, that gap is real exposure. Restricting management access to trusted internal addresses is the single most effective step while you wait, and Palo Alto's own scoring drops when access is limited to a jump box [10].

Protecting the Protector

Some of the most exposed systems in this incident are security appliances themselves. Palo Alto Networks, for example, confirmed that the PAN-OS management interface is affected, with fixed releases scheduled days after the PHP patch [10]. Many organizations run firewalls, gateways and security managers as virtual machines.

When such an appliance runs as a VM on VCF, its management interface is a vNIC like any other. That makes it possible to protect it with vDefend while you wait for the vendor fix, or for a maintenance window, which for critical security equipment is often the harder constraint.

• Micro-segmentation. Use the Distributed Firewall to allow the appliance's management interface only from a small group of jump hosts or administrator workstations, and drop everything else. This works regardless of encryption and matches the vendors' own guidance to restrict management access to trusted addresses [10].
• Check the exclusion list. Confirm the appliance VM is not in the Distributed Firewall exclusion list, otherwise no rule applies to it.

This does not replace the vendor patch. It shrinks the set of systems that can reach the vulnerable interface to the few that must.

Protecting PHP Workloads While You Patch

For PHP applications you run yourself, the fix is to update PHP. PHP states that updating is the only safe option and that configuration mitigations reduce exposure without making an installation safe [2]. Until every instance is patched, the goal is to reduce reachability and blast radius.

VMware has published specific guidance for vDefend and Avi [3]:

• Distributed IDS/IPS (distributed virtual patching): the critical-severity signatures 1156209, 1156228 to 1156231 and 1156240 for CVE-2026-109618, and 1156232 and 1156235 for CVE-2026-109619, all with a reject action, can be enabled on the Distributed Firewall and enforced at the vNIC of every PHP workload, wherever it sits on the network [3][16]. Distributed signatures inspect unencrypted traffic, so this fits workloads behind a load balancer or proxy that terminates TLS, such as Avi.
• Gateway Firewall with IDS/IPS: the same signatures at the north-south edge. With TLS inspection enabled, they also cover HTTPS traffic arriving from outside [3][17].
• Avi WAF: CVE-specific virtual patches in enforcement mode, plus core rule set protections for multipart anomalies and PHP application attacks, IP reputation and request normalization [3][9].
• Distributed Firewall micro-segmentation: ensures that a compromised PHP workload cannot reach databases, internal APIs or domain controllers, and cannot open unauthorized outbound connections [3].
• Advanced Threat Prevention: sandboxing suspicious uploads and blocking command-and-control callbacks after exploitation [3].

I described how these layers work together in AI Changed the Threat Landscape. VMware's Answer Is a Security Architecture That Fights Back at Machine Speed, and at the hypervisor layer in VMware HyperArmor: Proactive Host-Layer Defense for the AI Threat Era. PHP2Shell is a good test of that model: the vulnerability is in a runtime, not in your code, and exploitation began within hours of disclosure.

Finding PHP You Did Not Know You Had

Most organizations run more PHP than they think: web front ends, internal tools, monitoring dashboards and third-party appliances. The VCF team published a practical guide for finding it with tools VCF customers already have [15]:

1. VCF Operations service discovery identifies web servers and installed applications inside VMs through VMware Tools.
2. vDefend Security Intelligence maps traffic flows and, with the PHP2Shell signatures enabled, shows which workloads are receiving exploit attempts.
3. VCF Operations for Networks filters flows where the source is the internet and the destination is a VM.
4. Avi WAF reads Server and X-Powered-By headers in live traffic to reveal PHP versions.
5. vCenter tags and custom attributes turn the resulting VM list into a list of owners to contact.

The same guide makes two points that are easy to miss: update VM templates and content libraries so new VMs do not start out vulnerable, and patch systems restored from backup before they go back into service [15].

What This Case Teaches

PHP2Shell is not the first critical runtime flaw, and it will not be the last. What makes it worth studying is the sequence. AI models helped find and weaponize the bugs. Coordination took about two months. The embargo failed on the last day, exploitation attempts followed within hours, and a related issue surfaced two days later.

For infrastructure teams, the lesson is not to panic about AI-found bugs. It is to make sure the steps after discovery are fast and routine:

• Know where every runtime lives, including inside vendor appliances.
• Keep management interfaces off the internet, permanently, not only during an incident.
• Have virtual patching and segmentation ready to switch on, with TLS inspection where it is needed.
• Track vendor fixes for embedded components as their own patch stream, separate from your own servers.

The next PHP2Shell will arrive with the same pattern. The question is whether the gap between disclosure and verified protection is measured in hours or in weeks.

References

[1] PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet↗ - Wiz Research

[2] PHP News Archive 2026: security advisories of October 21 and October 23↗ - PHP

[3] Neutralizing PHP2Shell: Stopping Critical PHP RCEs with VMware vDefend and Avi WAF↗ - VMware Security Blog, October 22, 2026

[4] PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws↗ - The Hacker News

[5] PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors↗ - SecurityWeek

[6] PHP 8.4.27 Release Announcement↗ - PHP

[7] Impact Evaluation of PHP Issues CVE-2026-109618 and CVE-2026-109619 (KB 459989)↗ - Broadcom Knowledge Base

[8] vDefend: Impact Evaluation of PHP Vulnerabilities CVE-2026-109618 and CVE-2026-109619 (KB 460110)↗ - Broadcom Knowledge Base

[9] VMware Avi Load Balancer: Mitigation for CVE-2026-109618 and CVE-2026-109619 (KB 460068)↗ - Broadcom Knowledge Base

[10] Impact of Critical Vulnerabilities in PHP on Palo Alto Networks Products↗ - Palo Alto Networks

[11] PHP Core RCE Vulnerabilities (FG-IR-26-186)↗ - Fortinet PSIRT

[12] Vulnerabilities in PHP Affecting Cisco Products: October 2026↗ - Cisco

[13] PHP Remote Code Execution (CPAI-2026-15172)↗ - Check Point

[14] PHP Remote Code Execution: PHP2Shell↗ - watchTowr

[15] Vulnerability Response to PHP2Shell with the VCF Tools You Have↗ - VMware Cloud Foundation Blog, October 23, 2026

[16] Use Case: Configuring Distributed Virtual Patching↗ - Broadcom TechDocs, vDefend 9.1

[17] TLS Inspection↗ - Broadcom TechDocs, vDefend Gateway Firewall

[18] PHP2Shell↗ - Broadcom

Disclosure: The author is an employee of Broadcom. This article represents the author's technical analysis and does not represent Broadcom's official position.