PHP patches critical PHP2Shell flaws allowing unauthenticated code execution

The PHP project has released security updates for two critical vulnerabilities that can allow unauthenticated attackers to execute code on web servers running PHP.

The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively known as PHP2Shell, are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. The PHP security team rates both flaws 9.2 under CVSS v4.0 and says there are no complete mitigations, so updating is the only safe option.

According to the PHP security advisory, every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The team considers the risk highest for mod_php, citing a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

Two memory-handling bugs

Both flaws relate to how PHP handles memory when a request ends abnormally.

CVE-2026-109618, described by PHP as remote code execution via out-of-memory corruption, occurs when out-of-memory handling interrupts PHP while internal request data is only partly initialised. Request cleanup may then treat that invalid data as valid.

CVE-2026-109619, remote code execution via stale global state, occurs when request-owned internal state survives after its backing memory has been freed. A later request handled by the same worker may then use that stale state before normal initialisation resets it.

Cloudflare, which took part in the coordinated response, says the vulnerabilities affect web servers running PHP 5.4 or later and can lead to denial of service, remote code execution and data exposure. Because the flaws sit in the PHP runtime itself, updating website code or plugins does not fix them.

Leaked before release, attacks observed

PHP gave advance notice of the release on 20 October, scheduling it for 21 October at 14:00 UTC. The project said it reserved the right to release earlier if details became public or if active exploitation appeared.

Cloudflare says the vulnerabilities were disclosed by Calif.io, Wiz, OpenAI and Quarkslab, and that details leaked before the official release date. The company says it observed attack traffic targeting its customers, with attackers altering their payloads to try to bypass its protections.

Cloudflare's web application firewall rules have protected customers on free and paid plans by default since 3:02 am UTC on 21 October. The company still advises applying the PHP update, treating the firewall rules as an additional layer rather than a fix.

Older PHP versions

PHP 8.1 and older no longer receive updates from the PHP project. Given the severity of the flaws, the PHP security team has published minimal source backports for PHP 7.4, 8.0 and 8.1 for those building from source or without access to a long-term support vendor.

Linux distributions and long-term support vendors received the patches in advance, and PHP advises checking with vendors for updated packages. Users of the volunteer-maintained rpms.remirepo.net repository are urged to switch to distribution packages or build from source, as the repository would not carry updates on release day.

PHP also notes that PHP 8.2 reaches end of life on 31 December 2026 and will receive no security fixes after that date.

If you cannot update immediately

PHP stresses that only an update is a complete solution. The following measures reduce exposure to specific attack paths but do not make an installation safe.

For CVE-2026-109618:

• Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check that no other setting reintroduces a finite limit.
• Set a low post_max_size: 8M for applications that do not need file uploads, or 32M where uploads are required, keeping upload_max_filesize below post_max_size.

For CVE-2026-109619:

• Set session.upload_progress.enabled=0 and restart every worker, using php.ini, an FPM pool or server configuration that applies before request parsing. PHP warns not to rely on ini_set() or FPM .user.ini.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.

Organisations whose PHP is managed by a hosting provider should ask the provider to apply the security update.