Two critical PHP flaws patched early after leak leave unpatched servers exposed to RCE

A leak forced PHP's hand

On Monday, October 20, 2026, details of two critical vulnerabilities in PHP's core surfaced ahead of a planned coordinated disclosure. The PHP team responded by pulling its security release forward by a day and shipping fixes on Wednesday, October 21, according to a write-up on dev.to. Researchers have since named the pair of bugs PHP2Shell.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 under CVSS v4.0. According to the write-up, an attacker with no account and no credentials can execute arbitrary code on a vulnerable web server simply by sending a crafted HTTP request, with no action required from any victim.

Bugs in the runtime, not in your application

Both vulnerabilities sit in the machinery PHP uses to prepare and clean up each web request, which is what makes them so far reaching: the vulnerable code executes before an application's own code has any chance to defend itself.

The first flaw triggers when PHP runs out of memory partway through setting up internal request data. Cisco Talos, cited in the write-up, describes the outcome as cleanup routines later treating data that was never fully initialized as though it were valid. That memory confusion is what an attacker can steer toward code execution.

The second flaw is a close relative. Request-specific state can outlive the memory that backs it, so a later request handled by the same long-lived worker process, in PHP-FPM or Apache mod_php, can reach that stale state before normal setup resets it. Dead memory gets treated as live, and the attacker can exploit that window.

Neither flaw requires a bug in the application. Code that is clean, reviewed and fully patched can still be running on top of a broken runtime.

Updating your CMS does not fix this

A point the first wave of coverage missed, the write-up argues, is that PHP powers WordPress, Drupal, Joomla, Laravel applications and countless vendor tools, and updating those applications updates only the app layer, not the language underneath.

CISA, the US cybersecurity agency, lists the affected configurations plainly: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. It flags Apache mod_php as the highest risk, because the demonstrated exploit there fires before any site code runs.

Finding every PHP installation is the practical challenge. PHP hides inside months-old Docker images, inside vendor software that never mentions it, and on forgotten hosting accounts. CISA makes the same point, noting that PHP is often a component of other software and its presence may not be directly visible. The first step is an inventory, not a patch.

Fixed versions, and the restart step people skip

For supported branches, the fixed releases are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

The guidance is to install the fix for the branch you already run rather than jumping branches in a panic, since a branch change can break applications in ways a patch release should not.

The step most people skip is restarting every PHP worker afterward. PHP-FPM pools, Apache under mod_php, and queue workers all keep the old, vulnerable code in memory until they restart. Installing the patch on disk accomplishes nothing while an old worker is still serving requests.

There is no official patch for PHP 8.1 or earlier; those branches are out of support. The honest options, per CISA, are upgrading to a supported branch or taking the PHP-based system offline until it can be patched. A web application firewall may block some attempts, but both the PHP team and CISA are clear that patching is the only complete fix, since a firewall rule can miss a variant while a patched runtime cannot be exploited through these two flaws at all.

Attack attempts, but no confirmed breaches

Reports of early attack attempts circulated before and just after the patch, including from Cloudflare. The nuance matters: CISA stated that as of its alert, it had not observed successful exploitation in the wild. Attempted attacks are not confirmed break-ins, but the gap between attempts and success is exactly what patching closes.

An AI footnote

The write-up also reports that researchers, including a team at Wiz, credited frontier AI models with helping them trace and verify an exploit chain complicated enough that human researchers might have dismissed it as impractical. The flaw reportedly dates back to the PHP 5.4 era. The significance is not that AI finds every bug overnight, but that the cost of finding hard, old bugs has dropped, which shrinks the window defenders have to react.

Why it matters

PHP2Shell is a reminder that runtime vulnerabilities bypass every defense written into an application. Two layers of the stack, app and language, are patched by different people on different schedules, and assuming the first covers the second leaves servers open to unauthenticated code execution. With attack attempts already circulating, out-of-support branches facing an offline-or-upgrade decision, and worker restarts required to actually clear the flaw from memory, patch discipline has moved from admin chore to core security posture. The risk lives in the distance between a patch being available and being installed everywhere, with every worker restarted.