PHP2Shell: Two PHP RCE Bugs and the Only Safe Fix
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) exposes every PHP server back to 5.4. Here is what broke, what to upgrade, and what to do if you cannot.
PHP2Shell: Two PHP RCE Bugs and the Only Safe Fix
PHP shipped emergency fixes on 21 October 2026 for PHP2Shell, a pair of PHP RCE bugs in the interpreter itself. CVE-2026-109618 and CVE-2026-109619 both score CVSS v4.0 9.2 and reach every branch back to PHP 5.4. Fixed builds are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says updating is the only complete protection.
What PHP2Shell actually is
The nickname covers two memory-safety bugs in PHP core, not in any framework, plugin or theme. Wiz Research, which reported one of the bugs alongside work from Calif and OpenAI, says every PHP release of the past decade carries at least one of them. Because the flaws sit in the interpreter, a stock WordPress, Drupal, Joomla or Magento store is exposed even when its own code is clean, as Sansec demonstrated against Magento 2.4.9 and ten other applications. Every handler that reuses workers is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
The two bugs in plain terms
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) is an out-of-memory corruption path. PHP enforces memory_limit by aborting the request with longjmp, and that bailout can leave partially initialized request data behind. Shutdown code then treats the invalid state as valid and corrupts memory, per the PHP Foundation and CERT-EU. Wiz describes the reachable primitive as an upload-progress unserializer use-after-free. Their team demonstrated pre-authentication RCE against WordPress, Drupal and Joomla, plus an application-agnostic remote read of worker memory.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) is stale global state. A fatal error can free request-owned state while pointers to it survive, so the next request on the same worker inherits dangling references. Wiz pairs this with an OPcache type-confusion path and demonstrated pre-authentication RCE on Drupal and WordPress. The PHP Foundation confirms a use-after-free and a worker crash, and says the reporter achieved RCE against a real application running Apache mod_php. We found the clearest primitive breakdown in the Wiz research table, and we kept their naming for the two paths throughout this guide.
A disclosure that broke before the patch
Calif found the first RCE paths on 1 August and opened coordinated disclosure on 11 August, while Wiz reported its findings on 24 August, per the Sansec timeline. On 20 October the CVE IDs leaked publicly with a wrong CVSS 10.0 score. PHP moved the release forward a day and published an advance notice at 19:30 UTC.
Fixed builds landed on 21 October around 14:00 UTC, confirmed by CERT-EU. Cloudflare reported early attack telemetry that morning, and watchTowr observed active exploitation attempts against both CVEs that afternoon, as The Hacker News covered. We tracked the disclosure across the php.net notice, both GitHub advisories and the vendor write-ups while preparing this guide. We checked the CISA KEV feed on 22 October and found neither CVE listed; the freshest catalog at writing time was dated 21 October. We saw no confirmed breach report from any vendor either.
Who needs to move first
Internet-facing servers on supported branches, meaning 8.2 through 8.5, go first. Then anything hosting CMS or ecommerce code, then internal tools and CI runners. Tenable notes that 7.4 through 8.1 receive only minimal source backports from the PHP security team. Versions 5.4 through 7.3 are end-of-life with no official fix at all. If you run those branches, patching somewhere else will not help you.
How to upgrade, concretely
- Inventory every PHP runtime with php -v, including containers, sidecars and CI images.
- Pick the fixed build for your branch: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, per Qualys.
- Install through your channel: distro packages, LTS vendor or upstream tarballs. Linux distributions received the patches in advance.
- Restart every worker pool after install: PHP-FPM pools, Apache, LiteSpeed and FrankenPHP workers. A patched binary behind warm workers leaves the old code resident.
- Re-verify with php -v, audit your ini changes, then watch access logs for proof-of-concept shaped requests.
php -v
php -i | grep -E "session.upload_progress.enabled|fatal_error_backtraces"If you truly cannot patch today
PHP is blunt about this: no configuration change fully mitigates these flaws. Partial steps still shrink the window. Set session.upload_progress.enabled=0 and restart all workers to close the confirmed session path of CVE-2026-109619.
On PHP 8.5 also set fatal_error_backtraces=0, per The Hacker News and abstract.security. Block or rate-limit public upload endpoints at the WAF, and alert on new webshells or unexpected child processes. For legacy branches with no fix, we isolate the runtime instead of trusting it: run the old PHP inside a disposable microVM with no reach to production secrets. That is the same pattern we describe for untrusted code generally and for user-submitted workloads.
Where sandboxing fits your patch window
Even a fast team needs hours between advisory and fleet-wide restart. Treat that gap as an exposure window: freeze deploys, push the fixed image, and quarantine boxes that cannot move yet. Workloads that must stay on old PHP belong behind strong isolation. It is the same logic we apply to LLM-generated code and to microVM architecture choices.
Verdict
Patch first, mitigate second, isolate what you cannot move. PHP2Shell is interpreter-level, so application hygiene buys you nothing here. The partial ini toggles close single paths, not the bug class. With public proof-of-concept code circulating and exploitation attempts observed within hours of the leak, shipping the fixed builds is the only decision we would defend in an incident review.
Limitations
- We did not reproduce either exploit; all technical detail comes from the advisories and vendor research cited above.
- Exploitation claims reflect vendor telemetry as of 22 October 2026 and may have moved since.
- The 7.4 to 8.1 source backports are minimal by PHP's own description, and we have not tested their coverage.
- CVSS v4.0 9.2 is the PHP CNA rating; NVD published v3.1 9.8, so scores differ by catalog.
FAQ
What is PHP2Shell in one sentence?
PHP2Shell is the community nickname for CVE-2026-109618 and CVE-2026-109619, two critical use-after-free style RCE bugs in the PHP interpreter that were patched on 21 October 2026.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both CVEs. Branches 8.1 and older have no complete official fix, per Tenable.
Does disabling session upload progress fully protect me?
No. It closes one confirmed path of CVE-2026-109619 only. PHP states that updating is the only complete protection.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "BlogPosting",
"headline": "PHP2Shell: Two PHP RCE Bugs and the Only Safe Fix",
"datePublished": "2026-10-22",
"dateModified": "2026-10-22",
"author": {"@type": "Organization", "name": "Krova Cloud Engineering"},
"publisher": {"@type": "Organization", "name": "Krova Cloud"},
"mainEntityOfPage": "https://krova.cloud/blog/php2shell-critical-php-rce-patch-upgrade-guide"
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is PHP2Shell in one sentence?",
"acceptedAnswer": {"@type": "Answer", "text": "PHP2Shell is the community nickname for CVE-2026-109618 and CVE-2026-109619, two critical use-after-free style RCE bugs in the PHP interpreter that were patched on 21 October 2026."}
},
{
"@type": "Question",
"name": "Which PHP versions fix PHP2Shell?",
"acceptedAnswer": {"@type": "Answer", "text": "PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both CVEs. Branches 8.1 and older have no complete official fix, per Tenable."}
},
{
"@type": "Question",
"name": "Does disabling session upload progress fully protect me?",
"acceptedAnswer": {"@type": "Answer", "text": "No. It closes one confirmed path of CVE-2026-109619 only. PHP states that updating is the only complete protection."}
}
]
}
]
}
