TL;DR 

• Two critical PHP flaws, now patched: CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution, and PHP shipped fixes on October 21. WatchGuard's Red Cell Alert covers the immediate steps; this post looks at what the response exposed. 
• The fix was the clear part: the hard question was where PHP was running, including inside appliances and container images, and behind the SaaS services you depend on. 
• Attacks started before disclosure: Amazon recorded an exploitation attempt on October 17, four days before PHP's disclosure, and recommends starting investigations from that date rather than the advisory date. CISA has since listed both flaws as actively exploited. 
• The patch is necessary, not final: a regression and a narrow new RCE vector (CVE-2026-115560) mean more releases are coming. 

The Question Everyone Asked

When PHP shipped emergency fixes for two critical remote code execution flaws, the instruction was unambiguous: update. That part was never in doubt. 

The question that consumed security teams' attention came before it: where was PHP running? 

For an application, that question is usually easy. Someone chose it, someone deployed it, and it appears in a register. In this case, PHP means the interpreter rather than the language: the runtime that sits underneath every PHP application, often several layers below anything a team thinks of as software it operates. It arrives bundled inside other products, usually where nobody thinks to look. 

That distinction is the real lesson of the week, and it will outlast these two CVEs. Application vulnerabilities are largely inventory problems. Runtime vulnerabilities are discovery problems, and discovery is often far slower than remediation. 

Where a Runtime Actually Lives 

The hosts that show up in a scan for PHP are rarely the whole set, and the gaps are predictable enough to be worth naming. 

Appliances and network devices ship with embedded web interfaces, and the runtime underneath them belongs to the vendor's release cycle rather than yours. Vendor-supplied management consoles sit in the same category. Container base images include whatever was current when they were built, and an image nobody has rebuilt in a year carries a year-old runtime. Hosts originally deployed for a single purpose, such as a staging environment, a departmental site or a tool someone needed once, keep running long after the reason for them is forgotten. In practice, they become unmanaged IT, with no clear owner and nobody responsible for maintaining them. 

Then there is infrastructure that looks like yours but is not. Domains lapse and get picked up by someone else, and a third party's WordPress install can end up behind a name that still appears to be yours. The result is findings that cannot be acted on and a conversation nobody wants to have. Confirming ownership before acting on a finding is part of the search, not a step after it. 

None of this is new. WatchGuard's 2026 Cyber Hygiene Report, a survey of employees at small and midsized businesses across the US, Europe, Latin America and Australia, found that 39% of respondents said their organization does not maintain an accurate software inventory. In an ordinary week, that is a governance observation. During an out-of-cycle release for an unauthenticated RCE, it is the difference between patching and searching. 

What the Alerts Say About Finding It 

Versions, fixed releases and interim hardening are covered in WatchGuard's Red Cell Alert, and PHP's advisory remains the authority on all of it. What matters for this analysis is scope. PHP states that every installation serving web requests is at risk, and both CISA and the UK's NCSC list finding PHP as their first action. CISA notes that PHP is often a component of other software, so its prevalence may not be directly observable. The NCSC adds that discovery should not be limited to outdated versions, and that organizations should watch for updates from vendors of appliances and services that may bundle PHP. 

The Window Opened Before the Advisory 

The first recorded exploitation attempt came before the flaws were public. Amazon Threat Intelligence reports that its MadPot honeypot network recorded an exploitation attempt on October 17, four days before disclosure, from an IP address tied to a commercial anonymization network, and says it remains unclear how the actor obtained exploit information during the embargo. Amazon recommends starting any investigation from October 17 rather than from the disclosure date. The CVE identifiers themselves did not circulate publicly until October 20, which prompted PHP to bring its release forward by a day. 

PHP's advance notice, posted October 20. 

Since disclosure, the volume has been enormous. Exploit attempts climbed into the millions within a day, and Amazon describes PHP2Shell as broadly exploited in the wild based on attempts against its sensors. On October 26, CISA added both CVEs to its Known Exploited Vulnerabilities catalog. 

A reliable exploit has also been reported: VulnCheck says it chained both flaws to bypass ASLR and achieve remote code execution on x86-64 systems, even with PHP's recommended production error setting. The October 17 date matters more than any of this. For an organization that still does not know where PHP runs, it means not even knowing which systems to examine for activity since then. 

Why It Is Hard to See 

Going back to check is harder than it sounds, because this attack leaves little trace in the places most teams look. On mod_php, PHP says the demonstrated exploit runs before any application code does, so application logs may record nothing at all. One of the confirmed paths runs through session upload progress, which is triggered from inside multipart upload requests, and default Apache and Nginx access logs do not record request bodies. 

JPCERT/CC lists three signs worth checking: PHPSESSID cookie values that are unusually long or malformed in past HTTP responses; suspicious multipart requests followed by PHP memory-limit errors or HTTP 500 responses; and PHP workers that terminate abnormally or restart frequently. None of these is conclusive on its own, since healthy applications produce errors and crashes too. JPCERT/CC also warns that traces may not remain at all, so the absence of these signs does not show that no attack took place. PHP makes the same point about its own logs. Because PHP lists memory disclosure as a confirmed impact of CVE-2026-109619, an investigation that finds no web shell has not shown that nothing was taken. 

This is the visibility problem in miniature. The signals live in request bodies, response headers and process behavior, which conventional web logging was never set up to capture. Capturing them is not free either: logging request bodies and response headers can record credentials and personal data, and it adds storage and performance costs, so it calls for a deliberate decision rather than a reflex. 

Is the Patch Enough? 

Within a day of the release, claims that the patches were incomplete spread quickly, and they deserve a precise answer. One problem is real: the 8.4.27 and 8.5.12 releases also shipped with a regression, a SimpleXML garbage-collection bug that can crash workers. PHP has verified it and merged a fix into its source code, but as of October 28 the fix had not shipped in a release. Separately, reports circulated that further bugs survive the patch, including remote code execution through session handling. On October 23, PHP published an informational advisory confirming a narrow vector of that kind, now tracked as CVE-2026-115560. It requires an unusual setup: an application that sets session.serialize_handler to php_binary or php_serialize in its configuration, switches it to php at runtime with ini_set() before starting the session, and still has session upload progress enabled. PHP calls this unlikely in practice and will fix it in the next regular release, but has not yet said which versions are affected or whether the issue shares a root cause with CVE-2026-109619. 

None of this changes the core advice: patch. In the meantime, PHP suggests setting session.upload_progress.enabled=0 until its next bugfix release; applications that never change the serialize handler at runtime can leave it on. 

The Part You Cannot Patch 

Finding PHP has a second half that no amount of internal rigor resolves: a great deal of the PHP an organization depends on runs on infrastructure it does not own. SaaS platforms, payment processors, HR systems and support portals are built on the same runtimes as everything else, and when a flaw like this lands, each provider's decision becomes a condition its customers live with. A provider that restricts a public service while it patches hands its customers an availability problem. A provider that patches slowly hands them a data risk. In both cases, the options are to wait and to ask. When the vulnerable runtime belongs to a supplier rather than to you, patch management turns into vendor risk management. 

This played out in public within hours. In the Netherlands, government services, including the DigiD login system, went offline on October 21. Finland's state IT provider shut down public government web services as a precaution, and a Danish municipal IT provider suspended services, including the national school communication platform. The disruption came before any breach was publicly confirmed. For the citizens and businesses that depend on those services, the provider's decision was the incident. 

This is also the part most likely to surface outside the security function first, because an HR system going dark is visible to everyone, while an unpatched staging host is not. 

For MSPs, both halves multiply. One customer's unlisted PHP host is a finding. Across dozens of customer environments, each with its own appliances, vendor interfaces and portfolio of third-party services, the same problem becomes a search that urgency on the day cannot compress. 

What Mitigation Can and Cannot Do 

While patches are being deployed, the usual stopgap is a rule at the web application firewall (WAF), and CISA's alert notes that a WAF may provide some protection until systems are patched. 

One coverage condition is worth knowing, because it fails quietly. A rule at the edge inspects the requests that arrive at the edge. If an origin server also answers requests addressed directly to its IP address, those requests reach the application without ever passing through the rule. That is not a shortcoming of the WAF, and it stays invisible during normal operation, because ordinary visitors do arrive through the hostname. It matters only when the rule is the sole control standing in front of an unpatched runtime, which is precisely the situation an emergency disclosure creates. Testing a PHP path through the hostname confirms the rule is live; testing it against the origin address answers a different question: whether the rule is actually the boundary. 

The general point is the same one that runs through the rest of this post: mitigation inherits the gaps in your inventory and in the architecture beneath it. A rule only protects assets someone routed through it, and a patch only reaches hosts someone found. 

If You Cannot Upgrade 

According to Cloudflare, the flaws affect every web server running PHP 5.4 or later, a branch released in 2012, and the end-of-life branches are where most of the hard cases live. PHP published source backports for 7.4, 8.0 and 8.1 but no releases, and nothing for 7.3 and older. Moving an application from PHP 5 to a supported 8.x branch is rarely a patch-window job, because the jump tends to break code, extensions and dependencies along the way. 

That leaves a short list of real options. Some vendors have patched builds the PHP project no longer covers: AlmaLinux, for example, patched its retired 7.2 and 7.3 streams, and commercial extended-support providers offer builds for older branches. Where no patched build exists, CISA says to take such systems offline until they can be patched, and the NCSC says to consider doing so. Restricting access to a VPN or known IP addresses can serve as an interim step. A WAF in front can reduce exposure, with the origin caveat described above. 

What does not belong on that list is configuration alone. PHP's documented workarounds, such as removing the memory limit or disabling session upload progress, each close specific attack paths and carry their own operational costs, and PHP itself describes them as partial. Removing the memory limit, for instance, means relying on a container or cgroup limit to keep a runaway request from exhausting the host. PHP's advisory also does not say whether these measures hold on PHP 5. They buy time for a host that is going to be upgraded; they are not a reason to keep running one that is not. 

What This Means Going Forward 

PHP2Shell will be patched wherever patching happens, and in a few weeks it will read like any other critical CVE in the archive. The condition it exposed will remain. Knowing which runtimes are present and where is not an emergency activity. It is just usually treated as one. 

Closing the Gap Between the Advisory and the Answer 

For MSPs and defenders, three things determine how the next emergency goes: 

• Inventory runtimes, not just applications: track language runtimes and their versions wherever they appear, including the ones embedded in products and container images. 
• Know your third-party dependency map: maintain a current picture of which external services the business relies on, so that a provider's advisory can be matched to an actual exposure rather than a guess. 
• Verify that controls sit where you think they do: confirm that assets are routed through the protections meant to cover them, and that no direct path bypasses them. 

Patching remains the immediate answer, and the Red Cell Alert sets out the steps: apply PHP's releases without delay, and isolate anything on PHP 8.1 or earlier that has no patched build until it can move to a supported branch. The three steps above only pay off if they are in place before the next advisory arrives. 

The next runtime emergency will arrive with the same question: not how fast you can patch, but whether you already know where it runs. 

For more analysis of the threats, vulnerabilities and security trends shaping the industry, follow WatchGuard Technologies and subscribe to Red Cell Chronicles.