PHP2Shell Exploits Begin as Patches Hit Servers

The patches are out as of Tuesday: PHP 8.5.12, 8.4.27, and 8.3.36, each carrying fixes for CVE-2026-109618 and CVE-2026-109619, the two unauthenticated remote code execution flaws now widely labeled PHP2Shell. BleepingComputer confirmed the version numbers. Security sensors were logging exploitation attempts before the patching window had fully closed, which is more or less what happens now when critical vulnerabilities hit infrastructure deployed across this much of the web.

Cisco Talos characterized both flaws as triggerable by a plain HTTP request with no authentication, before any application logic runs. CVE-2026-109618 involves memory corruption during out-of-memory handling in the PHP runtime. CVE-2026-109619 involves stale global state that persists across requests and can be read before the runtime has properly reset it. NVD scores both at CVSS 9.8 critical.

KrebsOnSecurity noted that roughly 70 percent of websites use PHP. The Hacker News confirmed that WordPress, Drupal, and Joomla installs fall within the affected surface. SecurityWeek reported exploitation attempts reaching sensors within hours of Tuesday’s patch release, concentrated on those same high-profile CMS installs.

The PHP Foundation published a detailed account of how these went from introduction to disclosure: AI-assisted code review surfaced early signals in August, though at least one flaw traces back to 2024.

Earlier coverage on the initial disclosure: PHP Issues Emergency Patches for Two Critical RCEs.

Patching is the only real fix

Update the PHP runtime. The patched versions are PHP 8.5.12, 8.4.27, and 8.3.36. PHP 8.0 through 8.2 are past end-of-life and will not receive a fix; operators on those branches need a version upgrade, not a point release.

WordPress, Drupal, and Joomla do not update PHP. That fix lives at the server or hosting layer. Shared hosting providers are generally patching at the infrastructure level, but anyone managing their own PHP runtime needs to act. Rapid7’s analysis covers the exposure surface and available mitigations for those evaluating options while patching proceeds.

The gap that matters here

Web application firewalls, input validation, and application-layer security controls don’t protect against a flaw this far down the stack. Cisco Talos was explicit: the trigger is a plain HTTP request, unauthenticated, before the application runs. A server can be otherwise well-secured at the application level and still be exposed here.

The PHP Foundation’s disclosure showed that this class of flaw can live in PHP core for years before the right review surfaces it. The gap between “patch released” and “patch deployed across 70 percent of the web” is not measured in days for installs that never auto-update or that run on end-of-life branches. SecurityWeek’s sensor data confirms attackers understand that math.