Five days after PHP shipped emergency fixes, PHP2Shell (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2) has moved from mass scanning to confirmed remote code execution in the wild, and industrial vendors are now publishing bulletins for affected OT products. 

Latest PHP2Shell developments (as of October 26, 2026) 

The biggest change since the patch is that exploitation is no longer just noise. A honeypot operator has now documented a full remote code execution chain against a default-style Apache mod_php server, and a public proof-of-concept is circulating. Here is the sequence, newest first. 

Two further points matter for planning. Palo Alto Networks confirmed PAN-OS and Panorama are affected, with fixed builds rolling out through October 30. And Perforce Zend released patches for end-of-life PHP branches (7.2 through 8.1) for teams that cannot upgrade quickly.

What PHP2Shell is 

PHP2Shell is the name for two memory-safety flaws in the PHP engine itself, not in any application built on it. That distinction is why clean application code, a WordPress hardening plugin or a login wall does not protect you: the bug is reached while PHP parses the incoming request, before your code runs. 

• CVE-2026-109618 (CVSS 4.0: 9.2): remote code execution through out-of-memory corruption. When an allocation fails, PHP can be interrupted while request data is only partly initialized, and cleanup code then works on invalid state. 

• CVE-2026-109619 (CVSS 4.0: 9.2): remote code execution through stale global state. Request-owned internal state survives after its backing memory is freed, and a later request can read or branch on it. 

Researchers describe the affected areas as session handling, OPcache class caching and fatal-error backtrace generation. Datadog's analysis explains the practical trigger: PHP makes several copies of a form-field name while parsing, and an attacker sizes one field so the copying exhausts memory_limit at exactly the wrong moment. Exploitation also has to defeat ASLR, which is why early attempts mostly crashed workers rather than returning shells. 

The flaws were found with AI assistance by Calif, Wiz and OpenAI, with a coalition spending about two months preparing fixes. The vulnerable code dates back to PHP 5.4 (2012), so almost every deployed version is affected. 

PHP says every runtime that serves web requests is at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The project rates mod_php highest, because an unauthenticated request there has been shown to trigger the attack before any application code executes. 

Who is exploiting PHP2Shell, and how 

For the first four days after disclosure, honeypot operators including Previdian, Wordfence, Beelzebub and Dataminr reported plenty of scanning and crashed workers but no reliable code execution. That picture changed on October 25-26. The activity now falls into five groups. 

1. Mass scanning at internet scale. Cloudflare saw tens of thousands of exploit attempts within 45 minutes of disclosure, hundreds of thousands within two hours, and millions by early October 22. Cisco Talos described most of it as scanning plus uncoordinated payload attempts, which is what public PoC code produces before attackers build their own tooling. 

2. Botnet recruitment. Sophos and Arctic Wolf analyzed attempts to drop a Mirai-derived botnet called Potassium from three source IPs. The attempts failed, but the sample supports 24 flood-attack commands and carries an inactive Ethereum Name Service resolver for command-and-control. Sophos read the lack of successful infections as a sign that attackers were struggling to build reliable exploits. 

3. Financially motivated operators. SOCRadar found a one-click exploit script for PHP 8.4.26 under Apache mod php on an exposed attacker server, alongside screening scripts and tooling aimed at crypto and Web3 targets. Hunt.io tied the same server to probes of 123 hosts. About 57 ran PHP, and none was exploited. 

4. A suspected state-linked campaign. CYFIRMA reports low-volume, paced scanning from 21 compromised nodes against 216 unpatched or partially mitigated hosts, spanning government, finance, logistics, aviation, airports and manufacturing across the US, Asia-Pacific, the Gulf and the EU. It assesses, with moderate confidence, a Korean-speaking operator in the Lazarus Group ecosystem. This is a single vendor's attribution and has not been independently confirmed. 

5. AI-assisted intrusion. Palo Alto Networks Unit 42 described an attack on a European government entity in which the intruders reached password hashes and MFA secrets within two hours, built an NTLM-relay tunnel into Active Directory and attempted Domain Admin escalation. Command output wrapped in section delimiters suggested an AI agent was reading the results. Unit 42 states it could not confirm that initial access came through the PHP2Shell CVEs specifically, so treat this as a post-exploitation warning rather than proof of the entry vector. 

Two other signals deserve attention. Defused Cyber logged PHP2Shell probes carrying an upload-progress marker against its Palo Alto GlobalProtect honeypots on October 25, which suggests attackers are building target lists of security appliances. And Amazon's October 17 sighting means the safe assumption is that compromise can predate the advisory. 

On the confirmed-success side, the October 26 honeypot capture shows a usable memory disclosure feeding a payload, and VulnCheck says it has built an ASLR bypass that works on PHP's recommended production configuration. The practical reading: the barrier to reliable exploitation has fallen, even if most campaigns still fail.

How many systems are exposed 

Estimates range from hundreds of thousands to tens of millions, because each team counts something different. Use them as a range, not a single truth. 

The real exposure is larger than any scan, because PHP is embedded in appliances, hosting panels and vendor products that never show up as "PHP" on an asset list. Analysts already compare the tail to Log4Shell: fixes exist only for four PHP branches, and many vendors must ship their own updates. 

The operational impact has been visible. The UK government confirmed 32 digital services unavailable and four partially unavailable, largely from precautionary shutdowns, and the NCSC sent roughly 50,000 warnings. Reuters, CNBC and The Guardian reported government, school and hospital sites going offline across Asia, Europe and North America. The NSA and CERT-EU both advised taking systems offline if they cannot be patched or isolated. 

Patching and mitigation: what actually works

Only updating PHP on the host closes the hole. A web application firewall, a plugin update or an application code fix will not remove an engine-level memory bug. Treat everything else as a bridge to the patch window. 

1. Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's backported package. Then restart PHP-FPM pools and Apache workers. A host that still reports the old version after the update usually has a process that was never restarted. 

2. Verify the runtime that serves traffic. Qualys warns that the version, reports on the command line may not be the one behind your web server. Check containers, hosting panels, parallel PHP branches and base images too. 

3. Do not rely on the config workaround. Setting, blocks only the confirmed paths, and Datadog's analysis finds it does not fully protect you. 

4. Use WAF protection as a stopgap, not a fix. Cloudflare enabled default managed rules, but says request data alone does not always separate exploits from legitimate traffic, and it has seen attackers modify payloads to evade rules. Community rules that block, before it reaches PHP exist, but they are unofficial and will also break legitimate uploads and forms. 

5. Handle PHP 8.1 and older separately. There is no upstream release. Use distribution backports, a commercial LTS vendor, or the minimal backports PHP published, and plan the real upgrade. 

6. Isolate what you cannot fix. The NSA, the UK NCSC and CERT-EU all say to take unpatched internet-facing systems offline or isolate them until they are mitigated. 

7. Preserve evidence before you rebuild. Keep web, PHP and system logs before restarting servers. A patch closes the door but does not tell you whether someone already walked through it, and it does not remove web shells or persistence. 

Vendor appliances need their own track. Palo Alto Networks confirmed PAN-OS and Panorama are affected and had published the first fixed builds, with the remaining branches due between October 27 and 30. Cisco confirmed three affected products, and Fortinet was still assessing its lines at the last update. 

Detection and threat hunting 

No vendor has published confirmed indicators of compromise, and CrowdStrike notes that a successful attack can leave very few traces, so a clean search does not prove you are clean. Hunt on behavior, and start the clock on October 17, the earliest exploitation Amazon has reported, not on the disclosure date. 

If you find any of the first three, treat the host as compromised until proven otherwise: isolate it, image it, rotate every secret that the PHP process could read, and review the neighboring systems it could reach. Datadog also added cloud SIEM detections for suspicious command execution by web servers and PHP processes, and several scanners (Searchlight Cyber, Aikido, Xint) can test whether a host is exposed. 

A third flaw: CVE-2026-115560 

Two days after the emergency release, PHP published an informational advisory (October 23) for a separate remote code execution risk, CVE-2026-115560. It is not fixed by 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and PHP is not issuing an emergency patch. A fix is expected in the next routine release. 

The project considers it unlikely in practice because it needs a narrow setup. An application must set to php_binary or php_serialize, switch it to php at runtime with, do so before, and still have session upload progress enabled. 

The mitigation is one line: set, the same setting PHP already listed for CVE-2026-109619. If you applied it on October 21, nothing more is needed for this issue. PHP has not stated affected versions, a severity score, or whether the bug shares a root cause with CVE-2026-109619, and no exploitation has been reported. Do not let this one distract from patching the two critical flaws. 

Why PHP2Shell matters for OT and critical infrastructure 

PHP2Shell is a web-tier bug, but in industrial environments the web tier is rarely just a public website. PHP often rides inside a vendor product, such as an access control server, a line-monitoring system, an MES wiki or an engineering portal, and the plant team may not own the operating system underneath, so the PHP package misses the normal IT patch cycle. 

Industrial vendors started confirming this within two days of the patch. The list below is drawn from Red Tiger Security's summary of vendor bulletins as of October 23. Confirm each item against the vendor's own advisory before acting, and expect more bulletins. 

There is a counterpoint worth stating. Engineering.com reports that core ERP, PLM and MES platforms are generally not built on PHP, so the exposure sits in overlooked components around them: device consoles, supplier portals, legacy dashboards and third-party add-ons. Field controllers rarely run PHP, but the Level 3 servers around them often do. Viakoo's John Gallagher adds that the larger danger is an attacker using a compromised OT or IoT web interface, such as a building management system or industrial gateway, as a foothold for lateral movement. 

OT teams face constraints that IT teams do not. You cannot patch a live controller blind, vendor firmware cycles are slow, and some of the oldest embedded web interfaces will never receive a fix. That makes compensating controls the main defense for many assets: 

• Find PHP before you patch it. Inventory every asset that serves a web page, from the corporate DMZ down to the Level 3 operations servers, and ask each OEM and integrator in writing whether the product ships PHP and which version. 

• Cut exposure first. Remove internet reachability from any OT web interface, place it behind a firewall, and limit access to named administrative hosts. Pay particular attention to Level 3.5 DMZ servers and to physical access control servers, which often bridge security and corporate networks. 

• Patch in vendor-approved order. Use the vendor's fixed release where one exists, test it, and follow change control. 

• Watch what the web servers do. Alert on unexpected processes, new files and outbound connections from web-server accounts on OT hosts, because these systems often have no EDR. 

  
  

  CISO action plan: the next 72 hours and 30 days 

  
  

  Patching is necessary but not sufficient. Exploitation began before disclosure, a working exploit chain is now public, and AI-assisted tooling shortens the time between a patch and a weaponized exploit. Sequence the work like this. 

  1. Hour 0 to 24: close the exposed edge. Patch or isolate every internet-facing system running PHP, including appliances such as PAN-OS and Panorama. Where you cannot patch, take the system offline or restrict it to named source addresses. 

  2. Hour 0 to 24: preserve evidence. Copy web, PHP and system logs from October 17 onward before any restart or rebuild. 

  3. Hour 24 to 72: hunt. Run the detections in the hunting section against that window, starting with worker crashes, shells spawned by web-server accounts and unexpected files in web roots. 

  4. Hour 24 to 72: rotate. On any host with suspicious activity, rotate API keys, database credentials and anything stored in environment variables the PHP process could read, and review identity systems for the credential and MFA-secret theft pattern Unit 42 described. 

  5. Day 3 to 10: build the real inventory. Find PHP in containers, hosting panels, vendor appliances and OT products. Send OEMs and integrators a written question: does your product include PHP, which version, and when is the fix? 

  6. Day 3 to 10: brief leadership in plain terms. The message is that systems were probed or exploited before the patch existed, that patching started a response rather than ending it, and that suppliers' products are part of the exposure. 

  7. Day 10 to 30: retire legacy PHP. Put every 8.1-and-older runtime on a dated migration plan, with backports as a bridge only. 

  8. Day 10 to 30: harden OT access paths. Remove direct internet reachability from OT web interfaces, review Level 3.5 DMZ services, restrict administrative access to named hosts and add monitoring to web-serving OT hosts. 

  9. Day 10 to 30: fix the process. Add runtime ownership to your asset inventory, set a vendor patch-response expectation in contracts, and run a tabletop on a broken-embargo scenario where exploitation starts before a fix exists. 

     Do not treat a clean scan as closure. Forrester's Madelein van der Hout puts it well: a patch fixes the vulnerability but does not necessarily remove access an attacker already has. 

     How Shieldworkz can help 

     Shieldworkz is an end-to-end industrial OT cybersecurity company, with a platform, services and solutions for critical infrastructure operators. PHP2Shell is the kind of event where those pieces meet: finding hidden web components in OT environments, planning vendor-approved patching without disrupting operations, and isolating assets that cannot be patched yet. If you want a second opinion on your exposure, the team can help you scope it. 
     
     

     PHP2Shell FAQ

     What is PHP2Shell?

     It is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical (CVSS 4.0: 9.2) memory-safety flaws in the PHP engine that can give an unauthenticated attacker remote code execution on a web server. 

     
     

     Is PHP2Shell being exploited in the wild?

     Yes. Amazon logged an attempt on October 17, millions of attempts followed disclosure, and on October 26 researchers documented a confirmed remote code execution against Apache mod_php on PHP 8.4.26. Most observed activity is still scanning, and many attempts fail. 

     
     

     Which PHP versions are affected, and which are fixed?

     Versions back to 5.4 are affected. Fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older have no upstream fix, so use distribution backports or a commercial LTS vendor. 

     
     

     Does disabling session upload progress protect me?

     Only partly. It blocks some confirmed attack paths but does not fully protect you. Only patching does. The setting is still recommended for the separate CVE-2026-115560. 

     
     

     Is PHP2Shell on the CISA KEV list?

     In the reports reviewed through October 23, neither CVE was in CISA's Known Exploited Vulnerabilities catalog, although CISA urged immediate patching. Check the catalog directly, since the confirmed exploitation reports may change that. 

     
     

     Does PHP2Shell affect OT and ICS environments?

     Yes, indirectly. Schneider Electric, ABB, ProLeiT and B&R have published or acknowledged affected products, mostly web-serving servers around controllers rather than the controllers themselves.