PHP released emergency security updates on October 21 for two flaws that can let an unauthenticated attacker execute code on a web server. [1] Cloudflare says it has already observed attack traffic targeting the bugs, collectively called PHP2Shell, including changes to malicious requests aimed at evading its defenses. Its report does not establish whether those attempts led to successful compromises. [4]
Website owners should update the PHP runtime to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or install a vendor package that explicitly fixes both CVEs. Updating WordPress, a theme or a plugin does not replace that server-side repair. On managed hosting, ask the provider to confirm the patched package is actually running for your website.
A request can reach the flaw before the website runs
The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a critical CVSS v4.0 score of 9.2. PHP identifies Apache with mod_php as the highest-risk deployment: researchers demonstrated code execution through an unauthenticated HTTP request before the application itself started.
That timing matters. A login check or a carefully maintained CMS cannot protect code that has not started running yet. PHP first has to interpret incoming request data, and some of that work happens below the application’s security controls.
In CVE-2026-109618, an out-of-memory failure can interrupt PHP while internal request structures are only partly initialized. The subsequent cleanup can use those invalid structures. PHP’s advisory describes multipart request handling that can consume far more memory than the request’s apparent size suggests. Successful exploitation runs code with the web worker’s account permissions; it does not automatically grant root access. [2]
CVE-2026-109619 crosses the boundary between requests. A worker can retain internal pointers to memory belonging to a finished request. When that worker handles another request, an operation can touch the stale state before normal initialization replaces it. Session upload-progress handling is one confirmed route. It is enabled by default and does not require the application to call session_start(). [3]
PHP-FPM needs the update too
The strongest mod_php demonstration should not be read as a universal exploit for every PHP deployment. Build options, extensions, application behavior and request handling affect exploitability.
For the out-of-memory flaw, PHP says source analysis supports PHP-FPM susceptibility, while no complete FPM exploit for that specific flaw has been demonstrated. For the stale-state flaw, however, the advisory describes a validated FPM path: a suitable application operation leaves state behind after successful startup, a fatal error interrupts its cleanup, and a later request reaches it through upload-progress handling.
PHP therefore urges updates for all installations serving web requests, including FPM, mod_php, CGI, FrankenPHP and LiteSpeed. The different prerequisites explain the risk; they do not make switching handlers a complete remedy.
Which PHP packages contain the fixes?
| Upstream branch | Security release |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Distribution packages can carry the fixes under older-looking version numbers. Ubuntu’s October 21 notice, for example, lists 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS and 8.1.2-1ubuntu2.28 for 22.04 LTS. The full package revision and the vendor’s advisory matter when checking a backport. [5]
PHP 8.1 and older no longer receive supported releases from the PHP project. Some distributions and LTS vendors supply backports, and PHP’s security team has provided minimal source patches for 7.4, 8.0 and 8.1. Those patches do not restore normal support for obsolete branches. Obtain an explicit vendor fix or move to a compatible supported release.
Confirm the web worker was replaced
Inventory each PHP installation that serves traffic, including containers, hosting-panel runtimes and bundled web applications. Apply the relevant vendor update, then restart or replace the affected PHP workers so they load the corrected code. A host with several PHP versions can have one patched website and another still exposed.
The command-line result from php -v identifies that particular executable. It does not by itself prove which runtime an Apache module, FPM pool or container uses. Confirm the handler and package assigned to the website, then check that the application works after the update.
Cloudflare’s observed attempts make a web application firewall (WAF) useful additional protection, but PHP says only an update completely addresses the vulnerabilities. The project’s temporary settings cover particular paths and have operational consequences; disabling upload progress alone does not fix every variant.
Keep the runtime repair separate from incident recovery. If a site has unexpected files, accounts or outbound connections, patching does not establish that earlier access never happened. Preserve relevant logs and investigate those signs. The immediate decision is to get the running web stack onto a confirmed fixed package.
References
- PHP Group. Security advisory: Critical remote code execution vulnerabilities. October 21, 2026; accessed October 21, 2026.
- PHP Security Team. RCE via OOM corruption — CVE-2026-109618. GitHub Security Advisories, October 21, 2026; accessed October 21, 2026.
- PHP Security Team. RCE via stale global state — CVE-2026-109619. GitHub Security Advisories, October 21, 2026; accessed October 21, 2026.
- Molteni, D., Jones, D., and Nandwani, K. Cloudflare deploys protections against php2shell vulnerability. Cloudflare, October 21, 2026; accessed October 21, 2026.
- Canonical. USN-8948-1: PHP vulnerabilities. Ubuntu Security Notices, October 21, 2026; accessed October 21, 2026.
