CVE-2026-109618

What is PHP?

PHP is the server-side language behind roughly 70 percent of websites whose back-end language can be identified: WordPress, Drupal, Joomla, Magento, Nextcloud, MediaWiki, and an enormous long tail of custom applications. It is also embedded inside appliances and management interfaces from vendors including ABB, Broadcom, Citrix, F5, Okta, and Siemens, where the operator may not think of the box as "a PHP server" at all.

A flaw in PHP's own request handling is therefore not an application bug. It sits below every framework and every piece of application code, and it is reachable by anyone who can send an HTTP request. There is no plugin to disable and no route to firewall off.

Overview

CVE-2026-109618 is half of the pair published as php2shell. It is a memory corruption bug that an unauthenticated attacker triggers by deliberately exhausting PHP's memory_limit partway through parsing a request. PHP marks internal structures as populated before the allocations backing them have succeeded. When an allocation fails and the request dies with a fatal error, that half-built state is not rolled back, and the teardown code that follows reads and frees memory that was never initialised.

From there the attacker controls what the corrupted structure points at. Calif's write-up demonstrates pre-authentication code execution against stock WordPress 7.1.2, Drupal 11.4.3, and Joomla 6.1.4, running as the web server account before any application code executes.

Both php2shell CVEs score CVSS v4.0 9.2 from the PHP project; NVD rates this one 9.8 under CVSS v3.1. Exploitability in practice is genuinely contested and worth stating plainly. The PHP security team rates the risk highest for Apache mod_php. Red Hat judges reliable exploitation difficult under PHP-FPM, because workers exit on early initialisation failure before reaching the corrupted structures, and notes the vulnerable code is not even present in the RHEL 7 package. Sansec reported that the public proof-of-concept exploits do not work against a default installation. Against that, VulnCheck reported a working ASLR-bypassing exploit on x86-64 against unpatched PHP 8.4 with production settings, and two independent parties have now seen it land.

Affected Versions

The affected code path dates back to PHP 5.4.0. Every web SAPI is in scope: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Red Hat reports RHEL 7 is not affected by this CVE specifically, though it is affected by CVE-2026-109619.

Technical Details

NVD classes the issue as CWE-416, use after free. The more precise description is that cleanup runs over memory that was never properly initialised, which is the same failure mode with the free having happened implicitly rather than explicitly.

The concrete defect Calif documents is in _zend_hash_str_add_or_update_i, PHP's hash table insertion routine. It increments nNumUsed and nNumOfElements before performing the key allocation. If that allocation fails because memory_limit has been reached, the function bails out, but the counters have already claimed a bucket that contains nothing. Request teardown walks the table, treats the uninitialised bucket as a live entry, and operates on whatever pointer-shaped bytes happen to be there.

Forcing the allocation to fail at a chosen point is the real work, and it is achievable from a single HTTP request. The two methods described are bypassing post_max_size and sending a large number of small nested multipart upload records with empty filenames, which consumes memory_limit predictably. No authentication, no user interaction, and no valid application route are required, because the failure happens during PHP's own request parsing. The attack is a request, not a chain with another CVE.

Discovery

The research is credited to Calif, with OpenAI and Wiz also named as discoverers by the PHP project and Red Hat. The write-up is by Ryan Austin (@lcfr_hax) of Calif, who dates the breakthrough to 2026-08-01 after work tracing a lineage of related issues: Stefan Esser's 2004 memory-limit RCE, PHP bug #78876 from 2020, and a 2024 OSTIF and Quarkslab audit finding where exploitation was suspected but never proven.

The first bug went to the PHP project on 2026-08-11, a working RCE proof of concept followed on 2026-08-14, and PHP confirmed it on 2026-08-15. The second was reported on 2026-08-21. Volker Dusch of the PHP Foundation coordinated the disclosure. The release was scheduled for 2026-10-22 but moved to 2026-10-21 after the CVE identifiers leaked publicly the day before.

Exploitation Context

Exploitation is confirmed. watchTowr recorded attempts against its Attacker Eye honeypot network on 2026-10-21, the day of the release, and Cloudflare's CTO reported early attacks against both CVEs before the patches shipped. The clearest evidence came on 2026-10-24, when Adel Karimi of Perplexity reported a successful RCE against a honeypot: the response carried an 800 KiB decoded cookie dump, and the follow-up payload used a function address derived from that dump against the public exploit's offsets. His own caveat matters: the target was an intentionally favourable single-worker mod_php profile, so it does not establish reliability across worker counts, builds, or applications.

Censys estimates more than 32.51 million PHP services still running an affected version. No threat actor has been named, no ransomware use has been reported, and the activity so far reads as broad opportunistic scanning. CISA added both CVEs to KEV on 2026-10-26 with an unusually short three-day deadline of 2026-10-29.

Remediation

1. Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. This is the only complete fix; every published mitigation reduces exposure without closing the hole.
2. Inventory PHP everywhere, including interpreters bundled inside appliances, vendor management interfaces, and container images you did not build. Check vendor advisories for ABB, Broadcom, Citrix, Drupal, F5, Okta, Siemens, and WordPress.
3. On PHP 8.1 or earlier, which is end of life, either take the system offline until it can be moved to a supported branch or deploy a distribution or LTS vendor backport. CISA's advice is explicitly to take unsupported PHP offline.
4. As a temporary measure, set memory_limit = -1 so the allocation failure cannot be forced, but only where an external cgroup or container memory limit is in place. Red Hat warns against using RLIMIT_AS or RLIMIT_DATA for this.
5. Also set session.upload_progress.enabled = 0 and reduce post_max_size to 8M or 32M, keeping upload_max_filesize below it and enforcing limits at the proxy. On PHP 8.5, set fatal_error_backtraces = 0. Apply these with php_admin_value and restart workers; a reload is not sufficient.
6. Enable WAF coverage as an interim layer. Cloudflare's rule does not cover deployments that have changed session.upload_progress.name.
7. Review logs for PHP worker processes spawning shells or fetching tools, for oversized or deeply nested multipart POST bodies, and for anomalous response sizes consistent with memory disclosure. CISA publishes SIGMA rules for this in its GitHub repository.
8. Treat any host that was internet-facing and unpatched after 2026-10-20 as a candidate for compromise assessment rather than as merely unpatched, and rotate credentials readable by the web server account if anything is found.
9. Federal civilian agencies must remediate by 2026-10-29 under BOD 22-01.