Threat Advisory: Critical PHP2Shell Vulnerabilities

What UltraViolet Cyber is Doing

• Tracking new CVEs and high impact vulnerabilities, analyzing and deploying public Proof-Of-Concept code against custom built targets.
• Proactively enabling custom detections based on the intelligence available for the PHP2Shell vulnerabilities. UltraViolet is also maximizing detection coverage proactively through Equinox.
• Performing hypothesis driven threat hunts based on the intelligence available for the PHP2Shell vulnerabilities. UVCyber customers will be informed of the results through secure channels.
• Parsing available victim dump data for any social, financial, business, or technical relations to UVCyber Clients and partner organizations.
• Aggregating threat intelligence from myriad sources and applying the most up-to-date knowledge to proactive threat hunting and response.
  
  
  

VULNERABILITY PROFILE

CVE-2026-109618

Unauthenticated RCE via Out-of-Memory Corruption in PHP Core (PHP2Shell)

GHSA-w8hw-w9fx-j79w

VULNERABILITY PROFILE

CVE-2026-109619

Unauthenticated RCE via Stale Global State in PHP Core (PHP2Shell)

GHSA-6wmf-4rv5-p3rp

PHP2Shell is the collective name for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in PHP core that leaked publicly on October 20, 2026. The PHP Foundation responded the same evening with advance notice of an emergency release. GitHub Security Advisories for both flaws followed at 13:34 UTC on October 21, 26 minutes ahead of the 14:00 UTC fix. Both vulnerabilities permit unauthenticated RCE, but they are distinct bugs with different root causes.

CVE-2026-109618 arises from out-of-memory handling that can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat that invalid data as valid, corrupting internal state in a way an attacker can use to achieve remote code execution. CVE-2026-109619 arises from request-owned internal state that can survive after its backing memory has been freed, so a later request handled by the same worker process can use that stale state before initialization resets it, again resulting in remote code execution. PHP’s advisory does not publish an official CWE classification for either vulnerability.

Both vulnerabilities require no authentication, no special headers, and no targeted URL, and both reach every PHP SAPI that serves web requests, including PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP’s advisory rates the risk highest on mod_php deployments, where a demonstrated exploit can trigger the vulnerable path before any application code runs. A workaround that spread quickly on social media for CVE-2026-109619, disabling Session Upload Progress, was proposed and then retracted by the security firm that first suggested it, and PHP’s own core developers called it insufficient on its own. Per PHP core developer Gina Peter Banyard, the only real mitigation is patching or upgrading PHP, and PHP 8.6 release manager Joe Ferguson added that ini settings will not substitute for the fix.

The fix for both vulnerabilities were released together on October 21, 2026, at 14:00 UTC, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, the four branches PHP currently supports. Distributions received patches in advance of the public release, so organizations should check their vendor’s advisory for backported packages, confirm against the changelog rather than the version string, and avoid rpms.remirepo.net, which will not carry same-day updates. Notably, PHP 8.1 and all earlier branches are end of life and receive no official fix, while PHP 8.2 itself reaches end of life on December 31, 2026.

PHP2Shell presents a direct risk to shared hosting providers, managed PHP platforms, and vendor appliances that embed PHP without advertising it as a dependency. Because the defect sits in PHP core rather than in a specific application, organizations that rely on a hosting provider, a control panel such as cPanel or Plesk, or a vendor-supplied appliance cannot remediate it by patching their own application code; they depend on that provider or vendor to ship the underlying PHP update. Teams that only track the CMS or framework version in their asset inventory, rather than the PHP runtime underneath it, risk missing this exposure entirely.

Since both vulnerabilities require no authentication and reach PHP before any application-level access control runs, a threat actor only requires network access to a PHP-based web service to attempt exploitation. No stolen credentials, no social engineering, and no user interaction are required. Successful exploitation grants remote code execution on the underlying server, which a threat actor could use to install a web shell, move further into the network, exfiltrate data, or deploy payloads, depending on what that server can reach. Cloudflare reported early attack attempts before the patch even released, which shows how quickly adversaries move once technical details are available, and the two-day compression of the disclosure timeline, from the October 20 leak to the October 22 planned embargo, left defenders less time to prepare than the PHP Foundation had intended.

PHP2Shell follows a pattern seen in other critical vulnerabilities that live in a runtime or library embedded across many applications, rather than in any single product. The infamous Log4Shell (CVE-2021-44228) exploit, disclosed in December 2021, carried a maximum severity score and reached countless applications that embedded the Log4j logging library as an indirect dependency, often without the application owner’s knowledge, and many organizations spent months afterward just locating every place Log4j was buried in their own software. The XZ Utils backdoor (CVE-2024-3094), discovered in March 2024, pushed the same lesson further: a deliberately planted backdoor in the liblzma compression library, reached indirectly by OpenSSH through a chain of build dependencies on several Linux distributions, carried a maximum CVSS score of 10.0 and was caught only weeks before it would have reached the stable release branches most production systems run. Unlike PHP2Shell, that backdoor was intentional rather than accidental, but it proved the same point: a defect several layers down in the dependency chain can sit invisible to standard asset inventories and vulnerability scanners until someone examines the runtime itself, not just the application layered on top of it. PHP2Shell reinforces that lesson at the language level, since PHP core underlies the application rather than sitting beside it: when the defect lives in a runtime every application depends on, the visible asset inventory is not enough, and the vendor patch, not an informal workaround, is the response that holds up under real pressure.

• Tracking new CVEs and high impact vulnerabilities, analyzing and deploying public Proof-Of-Concept code against custom built targets.
• Proactively enabling custom detections based on the intelligence available for the PHP2Shell vulnerabilities. UltraViolet is also maximizing detection coverage proactively through Equinox.
• Performing hypothesis driven threat hunts based on the intelligence available for the PHP2Shell vulnerabilities. UVCyber customers will be informed of the results through secure channels.
• Parsing available victim dump data for any social, financial, business, or technical relations to UVCyber Clients and partner organizations.
• Aggregating threat intelligence from myriad sources and applying the most up-to-date knowledge to proactive threat hunting and response.