PHP2Shell: The PHP Remote-Code-Execution Flaw and What It Means for Industrial Web Interfaces

PHP2Shell is a pair of critical remote-code-execution flaws in the PHP language engine itself — not in any single website or app. Disclosed by the PHP project on 21 October 2026 and tracked as CVE-2026-109618 and CVE-2026-109619 (CVSS v4.0 9.2), the bugs let an unauthenticated attacker run code on a vulnerable server with a single crafted request. Because roughly 70% of the web runs on PHP, the immediate fallout was public-sector and consumer websites, not factories. The reason an industrial operator should still care is the second-order exposure: the web management interfaces, historian portals, and IT/OT bridge applications that sit around the control network. This guide explains what PHP2Shell actually is, who has issued warnings, what really happened in Japan, and how plant IT and OT teams should respond.

Key takeaways

• What it is: two memory-corruption flaws in PHP's core engine — one in out-of-memory handling, one in stale global state reused between requests — that chain into unauthenticated remote code execution.
• Who is affected: PHP 5.4 through early 8.x. Fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12; PHP 8.1 and older are end-of-life and have no backported patch.
• Who warned: national agencies and security vendors (NSA, UK NCSC, EU CERT-EU/ENISA, Japan IPA, China MIIT/CNVD, plus Wiz, Cloudflare, Akamai and Calif). As of this writing there is no confirmed joint PHP2Shell advisory from the major automation OEMs.
• The OT angle: the risk to a plant is the embedded web server on a managed switch, drive or HMI, and the PHP-based web apps on the IT/OT edge — not the PLC's deterministic control logic.
• The fix: upgrade the PHP runtime and restart the service, or take the interface offline. There is no complete workaround.

What PHP2Shell actually is

PHP2Shell is the community name for two flaws living in the PHP interpreter, reported to the PHP project in August 2026 by researchers at the security firm Calif — with AI-assisted code review — and independently by Wiz Research. Both are memory-safety bugs, and both are reachable before any login.

The first, CVE-2026-109618, sits in how PHP cleans up after running out of memory. When an allocation fails hard enough to abort a request, internal state that should have been discarded can survive. The second, CVE-2026-109619, is a use-after-free in the way PHP reuses global state between requests under a persistent worker model — the same worker that served one visitor can serve the next while still holding the previous request's leftover memory.

An attacker reaches these through ordinary web plumbing: a specially crafted multipart/form-data POST request, or the file-upload progress feature that ships enabled by default in many builds. No credentials, no click, no vulnerable application code is required — the flaw is in the language runtime, so even a minimal "Hello World" PHP page can be exposed. That is what makes it a Heartbleed- and Log4Shell-class event rather than a routine plugin patch.

Which versions are affected and how to patch

The affected range spans PHP 5.4 and later, with CERT-EU noting exposure potentially back to PHP 5. The PHP project released fixed maintenance versions on 21 October 2026:

• PHP 8.5 — upgrade to 8.5.12
• PHP 8.4 — upgrade to 8.4.27
• PHP 8.3 — upgrade to 8.3.36
• PHP 8.2 — upgrade to 8.2.35
• PHP 8.1 and older — end of life, no patch; migrate to a supported branch

Upgrading is the only complete fix, and the service must be restarted afterward because persistent PHP-FPM or Apache mod_php workers keep the old binary in memory. Temporary mitigations — disabling session.upload_progress, fronting the host with a WAF rule from Cloudflare, Akamai or AWS, and watching for abnormal multipart POSTs — reduce surface but do not close it. The PHP project's own wording was unusually blunt: there is no full mitigation, upgrade is the only safe option.

Who issued warnings — and what the automation vendors have not

The wave of public alerts came from government cyber agencies and security researchers, not from the control-system manufacturers. The US NSA, the UK's NCSC, the EU's CERT-EU and ENISA, Japan's IPA, and China's MIIT NVDB and CNVD all urged organisations to patch or take systems offline. On the vendor side, Wiz called it among the most severe flaws it has seen found with AI, Cloudflare and Akamai published detection guidance, and OpenAI — whose models assisted the discovery — announced a defender support programme and a Codex skill to check a PHP binary for the bug.

Reports that Siemens, Schneider Electric, ABB, Rockwell Automation and Johnson Controls had collectively published PHP2Shell advisories could not be confirmed at the time of writing. These vendors do maintain their own industrial-security (PSIRT) advisory streams and a regular ICS Patch Tuesday cadence, and those are the right places to watch for device-firmware guidance — but a PHP2Shell-specific joint bulletin from them is not something we can verify here. The honest takeaway is narrower and more useful: PHP2Shell is an IT web-layer problem, and its path into an industrial site is through the web-facing software around the controllers, not through the controllers themselves.

What really happened in Japan

Japan's response is the clearest illustration of how seriously the operators of PHP-dependent services took this — and it was a broad shutdown wave, not a single company. After the IPA issued its emergency warning on 21 October, Prime Minister Sanae Takaichi publicly advised that taking a site offline was a legitimate way to cut risk when a patch could not be applied in time. Railway operators Keihan, Hanshin and Hankyu paused corporate and service websites; JR East and JR West suspended some online functions; Shizuoka Bank took online banking down, with Daiwa Securities and Tokio Marine restricting web features; the Asahi Group, the Sushiro and Hamo group restaurant chains, and the cloud provider Sakura Internet all disabled PHP-based services; and several ministries — Finance, Health and Welfare, the National Tax Agency and the Weather Agency — limited parts of their portals.

One widely repeated example — that servo and drive maker Yaskawa Electric pulled its website on 21 October over PHP — does not appear in the verified reporting on the shutdown wave, so it should be treated as unconfirmed. What is confirmed is the pattern: when a core web runtime is compromised, the prudent first move is to switch the exposed interface off, then patch.

Why industrial devices are still in scope

A PLC, a variable-frequency drive or a safety relay does not run PHP in its control path — hard-real-time logic stays deterministic and close to the metal. The exposure is everything with a browser-facing management page, and modern automation hardware is full of them. Managed industrial Ethernet such as the Allen-Bradley Stratix 5700 switch, embedded web configuration on bridge modules like the 1756-ENBT ControlLogix Ethernet bridge, per-module web pages on distributed I/O such as Flex I/O, and the built-in web server on a drive like the PowerFlex 753 are all attack surface if they are reachable. Operator terminals and HMI and operator panels such as the PanelView Plus 1000 extend the same principle to the control-room screen.

The more direct PHP2Shell risk, though, is the software layer that genuinely uses PHP: historian and MES web portals, OEM configurator tools, vendor support and asset-management web apps, and the reporting dashboards that bridge the plant floor to the business network. Those are ordinary LAMP-stack applications, and they are exactly the kind of system that sits close to the OT network with weak segmentation. For teams maintaining that layer, the communication modules and sensors and instrumentation that feed it are worth inventorying alongside the servers, and the same firmware-check discipline applies across Allen-Bradley, Siemens, Schneider Electric and Bently Nevada condition-monitoring hardware alike.

A practical checklist for plant IT and OT teams

1. Find the PHP. Inventory every web-facing host — historian portals, MES dashboards, support tools, and any appliance that embeds a PHP stack — and record the PHP version. Anything 8.1 or older is both unsupported and vulnerable.
2. Patch and restart. Move to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 and restart PHP-FPM or the web server so the new binary loads.
3. Check device firmware. For switches, drives, HMIs and gateways, follow each manufacturer's PSIRT advisories and ICS-CERT notices rather than assuming a web page is safe because it is not "PHP."
4. Segment and de-expose. Keep management interfaces off the wide network and the internet; an embedded web server that is never reachable cannot be exploited.
5. Monitor for the signature. Alert on abnormal multipart POST traffic and on PHP worker processes spawning shells or downloading files.
6. Know when to switch off. If an exposed interface cannot be patched promptly, take it offline — the same call Japanese operators made — until it can be remediated.

The wider lesson connects to where industrial automation is heading: as platforms such as FactoryTalk Conductor and other AI-native orchestration layers add more web and API surface above the controller, the security perimeter of a plant keeps moving onto exactly the software this incident exposed. For background on the OT security and asset-management side, see our guides, and follow the rest of our coverage in Industry and Industry News.

Frequently asked questions

Is PHP2Shell a PLC vulnerability?

No. PHP2Shell targets the PHP language runtime, not programmable controllers. PLC control logic does not run PHP. The industrial concern is the web management pages on devices and the PHP-based web applications around the control network, which can be reached if they are exposed.

Does PHP2Shell affect Siemens, Allen-Bradley or Schneider devices?

Not through their control firmware, and no confirmed PHP2Shell-specific advisory from these vendors was verified at the time of writing. Their devices can still carry risk if they expose a web management interface to an untrusted network, so the correct action is to check each manufacturer's security-advisory feed and apply firmware updates as part of normal patching.

How do I know if my server is vulnerable?

Check the PHP version with php -v or a phpinfo() page on a trusted host. Any version from 5.4 up to but not including 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 is vulnerable, and 8.1 or older has no patch available.

Can I mitigate PHP2Shell without upgrading?

Only partially. Disabling session.upload_progress, fronting the host with a WAF, and monitoring for crafted multipart requests reduce the attack surface, but the PHP project states there is no complete mitigation — upgrading and restarting the service is the only reliable fix.

Why is this being compared to Log4Shell and Heartbleed?

Because the flaw is in a foundational, ubiquitous runtime rather than in optional application code, and it is reachable without authentication. That combination — huge install base plus pre-auth remote code execution — is what gave Log4Shell and Heartbleed their outsized impact, and it is why so many organisations chose to take sites offline preemptively.