Emerging Threat: php2shell (CVE-2026-109618, 109619) Critical PHP Remote Code Execution

Key facts

• CVEs: CVE-2026-109618, CVE-2026-109619
• Severity: CVSS v4.0 9.2, Critical, assigned by the PHP project
• Impact: Unauthenticated remote code execution on the web server
• Affected: Every PHP branch from 5.x onward. Fixes exist only for 8.2 and later
• Fixed in: 8.2.35, 8.3.36, 8.4.27, 8.5.12
• Exploited in the wild: Yes. Reported independently by Cloudflare and watchTowr
• Public exploit: Yes. Code claiming to implement php2shell is circulating
• Disclosure: Leaked ahead of embargo. Release brought forward by a day

What is php2shell?

php2shell is the name attached to two critical remote code execution vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, published by the PHP project on 21 October 2026.

The name places these flaws alongside Log4Shell: a defect in a runtime that most of the web is built on. PHP runs almost 70% of websites. It arrives underneath WordPress, Magento, Drupal, and many vendor-supplied and bespoke applications. A defect in the interpreter is inherited by every one of them.

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 a reliable way to drive the process into that condition: 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 session upload progress handling.

Timeline

• Early October 2026: Cloudflare begins developing WAF detections, weeks before any public advisory exists.
• 20 October 2026: Details leak ahead of the coordinated disclosure embargo. watchTowr publicly confirms the rumoured PHP vulnerabilities are real.
• 20 October 2026: The PHP security team gives advance notice of an emergency release set for 21 October at 14:00 UTC, covering two critical flaws, without naming CVE IDs.
• 21 October 2026, 03:02 UTC: Cloudflare deploys managed WAF rules to free and paid plans, roughly nine hours before the advisory goes public.
• 21 October 2026, 14:00 UTC: PHP publishes both advisories, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, and releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Disclosure had been planned for 22 October and was brought forward a day after the leak.
• 21 October 2026: The UK NCSC issues an alert urging organizations to update PHP immediately, and to consider taking systems offline where they cannot be updated.
• 21 October 2026: watchTowr’s honeypot network observes in-the-wild exploitation of both CVEs.
• 21 October 2026 onward: Cloudflare reports attack traffic reaching its customers, with attackers mutating payloads to evade detection. Code claiming to implement php2shell appears in public repositories.

Is php2shell being exploited?

Yes. Two organizations with independent visibility have reported it.

watchTowr’s honeypot network observed exploitation of both CVEs on the day of disclosure. Cloudflare, which sees traffic reaching a large share of the web, reported attack traffic targeting its customers and attackers actively mutating payloads to get past detections. Code claiming to implement a working exploit has appeared in public repositories.

Early reporting was more cautious and has since been overtaken. CISA’s vulnrichment entry recorded exploitation as none observed with automatable rated no, and in early coverage both watchTowr and Huntress said they had not yet seen exploitation. Sansec predicted mass exploitation would begin within minutes of the patch shipping.

The CVSS vector carries an attack complexity of high and an attack requirements rating of present. Those ratings describe the difficulty of a single successful attempt and say nothing about the size of the exposed population.

Which PHP versions are affected?

The PHP project’s own advisories list only the supported branches, because those are the only ones it ships fixes for. The defects themselves reach much further back.

An unsupported PHP install is in scope and will receive no fix.

Is your deployment affected?

Risk depends on the deployment model, and the advisories are specific about it.

Apache mod_php is the worst case. For CVE-2026-109618, full remote code execution was validated against mod_php over HTTP with default PHP input and memory limits and a normal prefork configuration. For CVE-2026-109619, remote code execution was demonstrated against mod_php on PHP 8.5 with fatal error backtraces enabled. Apache carries an additional exposure because .htaccess and directory-level php_value and php_admin_* settings are applied before request startup, so they read the affected state before initialisation completes.

PHP-FPM is conditionally exposed. For CVE-2026-109618 it is assessed as susceptible from source analysis, with no complete exploit demonstrated. For CVE-2026-109619 the session upload progress path was validated against FPM, requiring a suitable application operation and a dynamic process pool. FPM is also exposed where the frontend passes PHP_VALUE or PHP_ADMIN_VALUE parameters that trigger diagnostics.

FrankenPHP and LSAPI are assessed as likely susceptible, unvalidated.

Exploit reliability in every case depends on the build, the extensions loaded, frontend behaviour, and allocator layout.

What does our data show about exposure patterns?

Distribution by sector

Communication Services accounts for 25.87% of observed assets, Consumer Discretionary for 19.97%, Industrials for 12.57%. The remaining sectors make up 41.59%.

The spread is wide because PHP ships underneath WordPress, Drupal, Magento and Laravel applications, vendor appliances with a web console, and internal tools. Sector share tracks the number of public websites an organization runs.

Just under half the observed assets resolve to the United States, followed by the Netherlands, Germany and Bulgaria. For assets behind a CDN the recorded location is the edge or origin region.

Most observed assets are named web applications rather than bare IPs.Compared with a platform advisory such as Magento or Drupal, where a small number of large deployments carry most of the count, the distribution across estates here is flat. PHP appears in every estate in the data set.

Versions and end-of-life branches

Of the observed assets that expose a PHP version, 43.2% run PHP 5.x and a further 11.9% run 7.0 to 7.3, branches that will receive no fix for php2shell or for anything after it. Another 15.2% run 7.4, 8.0 or 8.1, where the only route is a distribution backport. Under three in ten run a branch with an official fix available. For the majority, remediation means a PHP upgrade or a platform migration.

PII data exposure

Roughly a fifth of the observed assets expose input fields that collect personal data. Detected field types are email address, name, physical address and phone number. Many are single-field newsletter or contact forms. A substantial share are longer: first and last name, work email with confirmation, home address, postcode, work phone, full helpdesk contact blocks.

Both CVEs give code execution in the PHP worker that parses those submissions. Under mod_php that is the Apache child handling the request. Under PHP-FPM it is a pool process that goes on to serve further requests. The attacker executes inside the process that handles form data in cleartext before the application receives it, which brings breach notification obligations into scope.

WAF coverage and enforcement

A WAF is detected in front of 57% of the observed assets. Of the assets with a known WAF status, 41.5% are protected by one and 58.5% are not.

Coverage and protection are measured as separate properties, so the shortfall is a difference between totals rather than a per-asset join. Roughly a third of assets with a WAF in front of them are not covered by it. The usual causes are a ruleset left in log mode, a hostname not proxied through the WAF, an origin still reachable directly by IP, or a plan tier where the managed ruleset is not enabled.

Where the product resolves, the most common are Cloudflare, Akamai Kona Site Defender, Varnish CacheWall, Google Cloud Armor and Wordfence. Wordfence is a WordPress plugin, so its share indicates how much of this estate runs WordPress.

Cloudflare pushed managed rules for php2shell roughly nine hours before the advisory was public. Those rules apply only to traffic traversing the WAF with enforcement enabled.

What to do about php2shell

Update. PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on 21 October 2026. Both advisories state that updating is the only complete mitigation.

PHP typically arrives as an operating system package, a vendor-maintained repository build, or a container base image, so remediation means waiting for a distribution package and then rebuilding and redeploying images. Backported distribution builds keep their original upstream version number, so a site can be patched while still reporting an affected version, and a rebuilt image from a stale layer cache can report a fixed version while being vulnerable. Where a hosting provider operates the site, that provider has to act; confirm with them.

Restart workers after updating. Both flaws live in long-lived worker processes. An updated binary with old workers still running is not patched.

Put a WAF in front of it. Cloudflare has deployed managed rules to both free and paid plans, including a default-block rule for high confidence signatures, and is updating them as attackers change payloads. Paid customers should confirm those rules are in block mode rather than log. In our data, a WAF is detected in front of 57% of observed assets, and 41.5% of assets with a known status are protected by one. This is defence in depth. Payload mutation is already reported, so the WAF does not replace the update.

Treat the interim settings as weak. Both advisories publish configuration measures and both say they are incomplete. For the out-of-memory flaw these include enforcing an administrative memory limit and restarting workers, enforcing decoded request size at the frontend with a conservative post_max_size, reducing input nesting, 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 warns specifically against using RLIMIT_AS or RLIMIT_DATA. For the stale global state flaw, sites on PHP 8.5 can set fatal_error_backtraces=0, and session.upload_progress.enabled=0 closes the validated session path. watchTowr goes further than the PHP advisories and states that .ini changes are ineffective. Either way, none of this replaces the update.

For end-of-life installs, there is no patch. Restrict access to anything running 7.3 or older until it can be migrated. For 7.4, 8.0 and 8.1, check whether the distribution has shipped a backport.

How to check for compromise

• Preserve web server and PHP logs now, before they rotate
• Look for unusually large or deeply nested multipart requests
• Look for PHP workers that crashed, restarted, or exhausted memory around the time of suspect requests
• Check web roots for unexpected files
• Check for outbound connections originating from PHP processes
• Enable full error logging with log_errors, error_log and error_reporting=E_ALL for ongoing audit

Clean logs do not prove a site was not reached. The advisories are explicit about that.

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.