What is php2shell?
php2shell is the name now attached to a pair of critical remote code execution vulnerabilities in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, published by the PHP project on 21 October 2026. The name is doing deliberate work. It places these flaws in the same category as Log4Shell: not a bug in one application, but a bug in a runtime that sits underneath an enormous share of the public web.
That framing is proportionate. PHP is used by almost 70% of websites according to W3Techs figures cited by Cloudflare, and it arrives underneath WordPress, Magento, Drupal, and a long tail of vendor-supplied and bespoke applications. A defect in the interpreter is inherited by everything running on it, whether or not the people operating those applications think of themselves as running PHP at all.
The PHP project rates both at CVSS v4.0 9.2 (Critical).
That score comes from PHP as the assigning authority and is carried in both GitHub Security Advisories. At the time of writing the National Vulnerability Database had not published its own analysis, so some third-party trackers may still show these as unscored. CERT-EU has assessed both as exploitable without authentication.
CVE-2026-109618 is remote code execution via out-of-memory corruption. PHP uses a long jump to abandon the current context when an allocation fails. Some contexts leave request memory reachable before it has been fully initialised, so a failed allocation can leave that memory in an invalid state, and the request shutdown routine then reads or branches on it. The advisory names multipart parsing as one reliable way to drive the process into that condition, through request bodies with no usable content length, unlimited headers per part, or large numbers of empty file fields.
CVE-2026-109619 is remote code execution via stale global state. PHP keeps global state that temporarily points into request memory. In a persistent worker that state is not always reset, or is repopulated after being reset, so it can still refer to memory that has already been freed. A later request then reads that stale state before initialisation completes. The producers are ordinary failure conditions: parse and compile errors, uncaught errors, a failed require, an execution timeout, or an out-of-memory event. The consumers run early, before normal request startup, in INI diagnostics and in session upload progress handling.
The two advisories cross-reference each other’s remediation, which is the clearest signal of how they should be treated. They share an affected range, a fix release, and a patch window. Handling one and deferring the other leaves a worker process reachable through the other path.
How urgent is this, and is it being exploited?
Details of these vulnerabilities leaked online ahead of the scheduled coordinated disclosure, which collapsed the usual gap between a patch becoming available and attackers understanding what to aim at. Cloudflare developed detections from early October and deployed WAF protections roughly nine hours before public disclosure, which is not a normal sequence of events.
On exploitation, the picture moved quickly and the sources do not all agree, so it is worth separating them. In reporting published around the release, watchTowr and Huntress both said they had not observed exploitation, and CISA’s vulnrichment entry recorded exploitation as none observed with automatable rated no. Sansec publicly predicted that mass exploitation would begin within minutes of the patch shipping. Cloudflare, which has direct visibility into traffic reaching a large share of the web, subsequently reported observing attack traffic targeting its customers, with attackers mutating payloads to evade detection. Code claiming to implement a working exploit has since appeared in public repositories.
Taken together: no confirmed mass compromise has been reported at the time of writing, but the leak, the pre-disclosure defensive scramble, and a major edge provider reporting live attack traffic put this well past the point where a wait-and-see posture is defensible.
The CVSS vector carries an attack complexity of high and an attack requirements rating of present, and CISA rates it as not automatable. Those ratings describe how hard a single successful exploitation attempt is, not how large the exposed population is, and they should not be read as a reason to deprioritise. The advisories are also specific that difficulty varies enormously by deployment, and in the worst configuration it is not difficult at all.
What assets are affected by php2shell?
This is where the public picture and the vendor advisory diverge, and the difference matters for scoping.
The PHP project’s advisories list the affected range as below 8.2.35, below 8.3.36, below 8.4.27, and below 8.5.12, with fixes in 8.2.35, 8.3.36, 8.4.27, and 8.5.12. That covers every currently supported PHP branch.
Cloudflare and Sansec both describe the flaws as affecting all web servers running PHP 5.4 or later, and wider reporting has repeated a claim that every version from PHP 5 onward is affected. The PHP project has not confirmed that range. The most straightforward reconciliation is that vendor advisories enumerate only the branches that receive fixes, while the underlying defects plausibly predate the supported branches by many years.
For defenders the practical consequence is the same either way, and it is not reassuring. If a site runs a supported branch, patch it. If a site runs an end-of-life branch, it is either affected with no fix coming, or it is running on a branch so old that it already carries years of unpatched issues. Treating an unsupported PHP install as out of scope because it predates 8.2 is the wrong conclusion to draw from this advisory.
The deployment model is the other variable, and it changes the risk substantially. For CVE-2026-109618, full remote code execution was validated against Apache mod_php over HTTP with default PHP input and memory limits and a normal prefork configuration. That is not an exotic setup. PHP-FPM is assessed as susceptible from source analysis but no complete exploit has been demonstrated against it, FrankenPHP is assessed as likely susceptible, and LSAPI as likely but unvalidated.
For CVE-2026-109619, two paths are confirmed rather than inferred. On PHP 8.5 with fatal error backtraces enabled, remote code execution was demonstrated against mod_php. The session upload progress path was validated against both mod_php and PHP-FPM, with the FPM case requiring a suitable application operation and a dynamic process pool. Apache deployments carry an additional exposure because .htaccess and directory-level php_value and php_admin_* settings are applied before request startup, which makes them an early consumer of exactly the state in question. PHP-FPM is exposed through this path only where the frontend passes PHP_VALUE or PHP_ADMIN_VALUE parameters that trigger diagnostics.
In practice an affected asset is any internet-facing web property serving PHP. Externally, the SAPI is rarely visible, the INI configuration never is, and the precise build often is not either.
What does our data show about exposure patterns?
Exposure in this set is led by Communication Services at 25.87% of observed assets, with Consumer Discretionary at 19.97% and Industrials at 12.57%. The remaining sectors together account for 41.59%.
This is by a wide margin the largest exposure set we have reported on, and that is the first thing the sector shares actually tell you. PHP is not a product an organization chooses once. It arrives underneath content management systems, marketing sites, intranets, ticketing tools, and vendor-supplied applications, often without a deliberate decision, which is why no sector dominates and why the tail outside the top three is so large.
Concentration is moderate. The largest single estate accounts for a bit over one in ten of the observed assets, and the distribution falls away steadily rather than sharply. Compared with the platform-specific advisories we usually report on, this is a broad footprint rather than a concentrated one.
Almost all of the observed assets are named web applications rather than bare addresses, which is what a web runtime footprint looks like from outside.
Geographically the set concentrates heavily in the United States, which holds close to half of the observed assets, with the Netherlands, Germany, and Bulgaria forming the next tier. For web properties behind content delivery networks and cloud hosting, those positions reflect where infrastructure sits more than where the business operates.
The version evidence is the most consequential part of this data, and it reads very differently once the disputed version range is taken into account. Among the observed assets that disclose a PHP version, the large majority are running a branch that is already end of life, with PHP 5.x and 7.x both well represented. On the PHP project’s stated range those hosts are out of scope. On the range Cloudflare and Sansec describe, they are squarely in scope and no fix is coming for them. The second reading is the one worth planning around, because even if these two CVEs somehow stop short of those branches, nothing else does.
Roughly half of the observed assets disclose no version at all, which is the usual state for PHP behind a reverse proxy with its banner suppressed. For this advisory that gap matters less than it normally would, since every supported branch is in scope, so the question external data cannot answer is not which version is running but which SAPI and which INI settings are in play.
The honest summary is that this data is a very good map of where PHP is reachable, and a poor map of where it is exploitable. The first is what you need to scope the patch campaign. The second has to come from configuration management.
Are fixes available?
Yes. PHP released 8.2.35, 8.3.36, 8.4.27, and 8.5.12 on 21 October 2026, and both advisories state that updating is the only complete mitigation.
The practical complication is that most organizations do not install PHP from php.net. It arrives as an operating system package, a vendor-maintained repository build, or a container base image, so remediation usually means waiting for a distribution package and then rebuilding and redeploying images. Backported distribution builds also keep their original upstream version number, so a site can be patched while still reporting an affected version, and the reverse is true for images rebuilt from a stale layer cache. Organizations whose sites are operated by a hosting provider need that provider to act, and should ask rather than assume.
Edge filtering is a genuine second layer here, in a way it often is not. Cloudflare has deployed managed WAF rules to both free and paid plans, including a default-block rule for high confidence signatures, and reports that it is continuing to update them as attackers mutate payloads. Customers on paid plans should confirm those rules are in block rather than log mode. Any WAF, Cloudflare’s or otherwise, is defence in depth and buys time; it is not a substitute for the update, and the reported payload mutation is a reminder of why.
Both advisories publish interim measures, and both are explicit that these are incomplete. For the out-of-memory flaw, the suggestions include enforcing an administrative memory limit setting and restarting workers, enforcing decoded request size at the frontend with a conservative post_max_size, reducing input nesting and limiting input variables, multipart parts, headers per part and uploads, blocking multipart requests at the frontend where the application does not use them, and applying a container or cgroup memory limit. The advisory specifically warns against using RLIMIT_AS or RLIMIT_DATA for this.
For the stale global state flaw, sites on PHP 8.5 that cannot update immediately can set fatal_error_backtraces=0 and restart workers, which covers only the confirmed backtrace case. Setting session.upload_progress.enabled=0 and restarting workers closes the validated session path, and the advisory recommends leaving that disabled after patching where the feature is unused. Other suggested risk reduction includes removing attacker-reachable fatal errors, eliminating INI diagnostics that run before request initialisation, considering a worker request limit of one, and treating execution timeouts as fatal errors.
One caution carried in the advisory is worth repeating. Enabling full error logging is recommended for audit, but clean logs do not prove a site was not reached.
Are there any other recommended actions to take?
Given the leak, the available exploit code, and reported attack traffic, defenders should:
- Update to 8.2.35, 8.3.36, 8.4.27, or 8.5.12 according to branch, through the distribution or base image that supplies PHP, and treat this as an emergency change rather than a scheduled one
- Inventory internet-facing PHP by SAPI, not only by version, and separate mod_php from PHP-FPM, FrankenPHP, and LSAPI
- Treat Apache mod_php deployments as the highest priority, since remote code execution was validated there under default settings
- Confirm WAF managed rules covering these CVEs are enabled and set to block, not log, and keep them enabled after patching
- Rebuild and redeploy container images rather than assuming a running image picked up the fix
- Ask hosting providers and managed service partners directly when they will patch, rather than assuming they have
- Check whether session upload progress is enabled, and disable it where the application does not use it
- On PHP 8.5, set fatal error backtraces off until the update lands
- Review whether the frontend passes INI values to PHP-FPM, which is the condition that exposes the FPM path
- Apply the published request size, multipart, and input limits at the frontend as interim hardening
- Treat end-of-life PHP installs as in scope and urgent, not as not applicable, and plan migration rather than patching
- Enable full error logging for audit, while treating clean logs as inconclusive
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-109618 and CVE-2026-109619 in the CyCognito platform and is actively researching enhanced detection capabilities for these vulnerabilities.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
