Two Critical PHP Flaws Leaked Ahead of the October 21 Security Release

Update, October 21, 2026, 17:30 UTC: PHP has released the fixes. This article now includes the fixed versions, details of both vulnerabilities, the PHP team’s interim measures, reports of exploitation and the first control panel updates.

On October 21, the PHP project released fixes for two critical vulnerabilities that can allow unauthenticated remote code execution. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP security team strongly encourages all users to update immediately. Information about the flaws, tracked as CVE-2026-109618 and CVE-2026-109619, had leaked a day earlier, ahead of the coordinated disclosure.

Exploitation attempts have begun. According to watchTowr, its global honeypot network has observed exploitation of both vulnerabilities in the wild, and Patchstack’s telemetry showed probing attacks shortly after the release, without hard evidence of breaches at that point. CERT-EU notes that initial proofs of concept have begun to circulate.

What the Two Vulnerabilities Do

Both flaws are rated 9.2 under CVSS v4.0, according to the PHP project’s GitHub security advisories, which also score the attack complexity as high. CVE-2026-109618 is a remote code execution flaw through out-of-memory handling: PHP can be interrupted while internal request data is only partially initialized, and request cleanup may then treat that invalid data as valid. CVE-2026-109619 involves stale global state: request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use it before normal initialization resets it.

According to the PHP team’s security advisory, all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The team considers the risk highest for mod_php, with a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs.

Fixed Versions and Older Branches

The four releases cover the branches the project supports, PHP 8.2 through 8.5. Linux distributions and long-term support vendors received the patches in advance, according to the advisory, so updated packages may come from them rather than from php.net.

PHP 8.1 and older no longer receive updates from the PHP project. Given the severity, however, the security team provided minimal source backports for PHP 7.4, 8.0 and 8.1 for those building from source or without access to an LTS vendor, and it points users of these branches to their vendors or to an upgrade.

What to Do Before Updating

For installations that cannot update immediately, the advisory lists measures that reduce exposure to specific attack paths while stating that they do not make an installation safe. For CVE-2026-109618, they include setting memory_limit=-1, preferably in a way applications cannot override, setting a low post_max_size (8M where file uploads are not needed, 32M where they are) and considering request limits at the web server or proxy. It also recommends a container or cgroup limit as an availability boundary, preferably one that kills only the affected worker.

For CVE-2026-109619, the advisory recommends setting session.upload_progress.enabled=0 in php.ini, an FPM pool or the server configuration and restarting every worker. It warns not to rely on ini_set() or FPM .user.ini files, and notes that this blocks the confirmed session paths but not other variants. On PHP 8.5, it also recommends fatal_error_backtraces=0.

CERT-EU’s updated advisory calls for patching affected assets immediately. Where that is not feasible, it suggests considering isolating internet-facing applications from public networks until a fix is applied and verified.

Patchstack, a security company that works with hosting providers, suggests finding every PHP installation in use, including servers, containers, staging sites and appliances or third-party software that bundle PHP. It warns against unofficial “fix” plugins and copied code snippets, which are unverified and can break a site.

How Fast the Fixes Reached Hosting Platforms

This time, cPanel and Plesk shipped the fixed versions on the day of the release. EasyApache 4 update 25.91 from cPanel, dated October 21, moves its PHP 8.2 through 8.5 packages to the fixed versions and backports the fixes to ea-php74, ea-php80 and ea-php81. Plesk’s change log lists the four fixed versions under PHP Updates on October 21.

In the two previous PHP security rounds, the updated versions appeared in the vendors’ change logs and security announcements on these dates:

These dates reflect vendor-published package updates, not when individual hosting providers installed them.

How the Disclosure Unfolded

The PHP project announced the release on October 20 and scheduled it for 14:00 UTC the next day. Information about the flaws leaked the same day, when Kevin Beaumont posted that the two CVEs had leaked and watchTowr stated that it could confirm they are real. The PHP project’s GitHub advisories for both flaws were published on October 21 at 13:34 UTC.