PHP vulnerability fixes close two critical RCE flaws
The PHP vulnerability fixed on 21 October 2026 consists of two critical flaws that can let an unauthenticated attacker, meaning someone who has not logged in, remotely run code on a web server. PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to address both issues. Websites using WordPress, Drupal, Magento, Joomla, Laravel or any other PHP application are exposed when the underlying PHP installation remains vulnerable.
The risk applies across the main ways PHP processes web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk configuration because a malicious request can reach the flaw before the website’s own application code begins running. The problem is inside the PHP interpreter, the software that executes PHP code, rather than in a particular content management system or plugin.
The flaws are CVE-2026-109618 and CVE-2026-109619, each rated Critical at 9.2 under CVSS v4.0, a standard system for describing vulnerability severity. CVE-2026-109618 involves out-of-memory handling. PHP can be interrupted while its internal request information is only partly prepared, after which cleanup may mistakenly handle invalid information as legitimate. CVE-2026-109619 allows request-specific internal information to remain after its memory has been released. A later request processed by the same worker, the PHP process handling requests, can use that stale information before normal setup clears it.
Wiz Research, which reported the vulnerabilities to PHP, says every PHP release back to 5.4 is affected by at least one flaw. Its researchers demonstrated remote code execution against the latest WordPress, Drupal and Joomla container images, as well as exploitation of a basic Hello World application. A container is an isolated package containing an application and its required software. The researchers also demonstrated reading PHP worker memory without first achieving code execution. That memory may contain passwords, API keys and access tokens. Wiz says PHP’s patch corrects the underlying problem, including additional variants.
Details leaked on 20 October before the planned coordinated disclosure, and the issue became known as PHP2Shell. Security company watchTowr confirmed before release that the vulnerabilities were genuine. At 07:34 UTC on 21 October, multiple hosting partners reported active exploitation incidents to Patchstack. Cloudflare reported early attacks at 07:43 UTC and deployed initial Web Application Firewall rules, which inspect and filter web requests, for known exploit routes. At 13:52 UTC, PHP published the fixed releases. Five minutes later, Patchstack said its own telemetry showed probing but no hard evidence of breaches at that point, while warning that this could change as patch details became public.
Several services went offline as a precaution before the fixes arrived. Dutch broadcaster NOS reported outages affecting DigiD, MijnOverheid, the Dutch House of Representatives’ website, Tweakers and the Dutch National Cyber Security Centre’s site. ITmedia reported emergency maintenance at Japanese services including Kodmon, Shadowverse: Worlds Beyond and Sakura Rental Server, believed to be connected to the vulnerability, with BASE and Xserver expected to follow. The SEO Framework’s developers also said they had taken their servers offline. CERT-EU issued an advisory, while the UK National Cyber Security Centre urged immediate updates.
Cloudflare says its initial firewall rules are available to all customers, including free users, but describes them only as a temporary barrier. They help only when the origin server accepts traffic exclusively through Cloudflare. They do not replace the PHP security update because other routes to the server or previously unknown attack variants may remain available.
Administrators should install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or obtain the corresponding patched package from their operating-system vendor. Linux distributions and long-term support vendors received advance patches. PHP warned that volunteer-maintained rpms.remirepo.net packages would not be updated that day, recommending distribution packages or a source build instead. PHP 8.1 and older no longer receive fixes from the PHP project, although several outside maintainers backported the correction, meaning they adapted it for older releases.
Package availability varied as of 22 October. Packages from packages.sury.org and ppa:ondrej/php covered end-of-life branches from PHP 5.6 through 8.1, and Ubuntu 22.04 patched its PHP 8.1 package as php8.1 8.1.2-1ubuntu2.28. Ubuntu Pro covered releases from 14.04 through 20.04, with 14.04 and 16.04 requiring the Legacy add-on. Freexian ELTS covered PHP 7.0 on Debian 9, 7.3 on Debian 10 and 7.4 on Debian 11. Debian’s own support for Debian 11 ended on 31 August 2026, although Sury’s php7.4 package provided a free route.
AlmaLinux published fixes for PHP streams on versions 8, 9 and 10, including end-of-life streams, but did not guarantee future fixes. Red Hat had fixes for php:7.4 on RHEL 8 and PHP 8.0 on RHEL 9, but not retired streams such as 7.2 and 8.1 on RHEL 9. Remi covered 7.4, 8.0 and 8.1 on RHEL 8 and 9, but not 7.2 or 7.3. CloudLinux released corrected EasyApache 4 ea-php packages from ea-php52 through ea-php85 for cPanel. TuxCare ELS was rolling out branch-specific fixes, while Zend said its long-term support builds of PHP 7.2, 7.3, 7.4 and 8.1 were patched at release. Official PHP Docker images received no fix for PHP 8.1 or earlier.
PHP also published source backports for 7.4, 8.0 and 8.1 as a last resort. These are limited mitigations, not renewed support: they disable session upload progress regardless of php.ini and add no hard memory limit. On Ubuntu and older Sury builds that retain upstream version numbers, administrators should inspect package changelogs for both CVEs. Debian and newer Sury packages may list only a new upstream version, while RHEL 8.2 and 8.3 stream changelogs may say only rebase; PHP advises using dnf updateinfo there. If no vendor fix exists, move to a supported release. PHP 8.2 receives security fixes only through 31 December 2026 and PHP 8.3 through 31 December 2027, so PHP recommends aiming for 8.4 or 8.5.
Every PHP installation needs attention, including production servers, containers, staging sites, appliances and third-party products that bundle PHP. Unofficial fix plugins and copied code snippets should be avoided because they are unverified and may break a site. If a high-risk service cannot be patched immediately, taking it offline or placing it in maintenance mode is an option also recommended by the UK NCSC.
Only updating fully fixes the PHP vulnerability.