Note: This topic is quickly evolving. The following article is our take on it as of 10/23/26.

On October 21, the PHP project shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix PHP2Shell, a pair of critical flaws in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code (RCE) execution with the privileges of the Web Worker. Both sit beneath the application, so a clean WordPress install offers no protection on its own. CISA issued an alert the same day urging immediate patching, and exploitation attempts began before the fix existed. 

What the Two Bugs Actually Do

CVE-2026-109618 is memory corruption in out-of-memory handling. When an allocation fails, PHP jumps out of the current operation, and in some code paths it does so while request data is only partly initialized. Cleanup then trusts that invalid data. The advisory lists several ways to force the failure with crafted multipart requests that stay inside PHP’s apparent limits, including parts carrying an unbounded number of headers. Under Apache mod_php, cleanup runs even when request startup fails, so the attack completes before any application code executes.

CVE-2026-109619 is a Use-After-Free (UAF) vulnerability across requests. Error, session and extension state can outlive the request that owns its memory, and a later request on the same worker can touch that stale pointer before normal initialization resets it. The confirmed paths run through PHP 8.5’s fatal error backtraces and through session upload progress, which is on by default and does not need the application to call session_start().

Both carry a CVSS v4.0 score of 9.2 with attack complexity rated high. The advisories explain why: Exploit reliability depends on the PHP build, loaded extensions, allocator layout and, for the second bug, landing two requests on the same worker.

Who Is Exposed

The PHP project says every installation serving web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and it rates mod_php highest. FPM is susceptible, though the advisory reports no complete FPM exploit for the memory corruption bug.

Branch matters as much as server type. Fixed releases exist for 8.2 through 8.5 only. PHP 8.1 and older no longer receive updates from the project. Given the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1; anything older depends on a distribution or LTS vendor. Linux distributions and LTS vendors received the patches in advance, so check vendor packages before building from source.

Exploitation is Early, Noisy and Unproven

Amazon Threat Intelligence logged an exploitation attempt against its MadPot honeypots on October 17, four days before the embargo was lifted. Proof-of-concept (PoC) code circulated hours before the release and multiplied after it, and Amazon now describes broad exploitation attempts from what looks like multiple actors. Amazon also says it is unclear whether any of those attempts would have succeeded against real systems. 

Rapid7 reviewed the public PoCs and found that each works only against a narrow combination of operating system, PHP version and web server. They have not observed successful exploitation in the wild. 

PHP’s own advisory, though, reports RCE validated against mod_php with default input and memory limits. JFrog also found fake PoCs on GitHub.

Rapid7 calls the current difficulty a window to patch, not a reason to wait. Amazon adds that AI-assisted analysis is shrinking the time between a patch and a working exploit.

What You Should Do

Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package carrying both fixes, then restart every PHP worker. PHP states that updating is the only complete fix.

Inventory before declaring victory. Containers, vendor appliances, hosting control panels and build servers can carry their own PHP.

Where patching has to wait, set session.upload_progress.enabled=0 in php.ini or pool configuration, not through ini_set() or .user.ini. PHP suggests leaving it off even after patching if the feature is unused. On 8.5, also set fatal_error_backtraces=0. For the memory corruption bug, PHP suggests enforcing memory_limit=-1 administratively alongside a conservative post_max_size and request limits at the proxy. Each measure closes a known path and nothing more.

If an application never accepts multipart uploads, block them at the proxy.

Hunt from October 17 forward, not from the patch date. Look for POST requests containing PHP_SESSION_UPLOAD_PROGRESS, unexpected process execution on web servers, and modified files in web roots. PHP notes that clean logs are not proof of safety, and that suppressing diagnostics with error_reporting, display_errors or @ does not reduce exposure.

PHP2Shell is a reminder that the runtime environment is part of the attack surface, even when nobody on the team thinks of it as software they own. The current publicly available exploits may or may not develop into something more reliable for attackers, but in either case, patching is the safest bet.

‍

Published By: Daniel Parker, VP of Ethical Hacking, NetWorks Group

Publish Date: October 23, 2026

Sources

PHP. “Security advisory: Critical remote code execution vulnerabilities, update now.” 21 October 2026. php.net/archive/2026.php#2026-10-21-5

PHP. GHSA-w8hw-w9fx-j79w, “RCE via OOM corruption” (CVE-2026-109618). 21 October 2026. github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

PHP. GHSA-6wmf-4rv5-p3rp, “RCE via stale global state” (CVE-2026-109619). 21 October 2026. github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

CISA. “Critical Vulnerabilities in PHP Require Immediate Patching.” 21 October 2026. cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

Amazon Web Services. CJ Moses, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot.” 21 October 2026, updated 22 October 2026. aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot

Rapid7. “CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP.” 21 October 2026, updated 22 October 2026. rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php

JFrog Security Research. “PHP2Shell: All You Need to Know About CVE-2026-109618 and CVE-2026-109619.” 21 October 2026. research.jfrog.com/post/php2shell-all-you-need-to-know-about-cve-2026-109618-and-cve-2026-109619 (edited)

‍