A leak, a day early
PHP planned to disclose two critical flaws on 22 October. On the morning of 20 October a post on Hacker News revealed them ahead of time. It was taken down, but the security firm watchTowr confirmed the flaws were real, and PHP moved its release forward to 21 October, 14:00 UTC.
| When (UTC) | What |
|---|---|
| 20 October | Details leak on Hacker News; watchTowr confirms the flaws. PHP announces security releases for 21 October, 14:00 UTC. |
| 21 October, 07:49 | Shieldify's WAF starts refusing requests on the attack path the leaked proofs of concept used, on every website with the WAF on. |
| 21 October, 13:34 | PHP publishes its two advisories and releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. |
| 21 October | watchTowr reports exploitation in its honeypot network. |
| 21 October, 23:15 | Shieldify adds the limits on multipart requests that PHP's advisory recommends at the frontend. |
Memory bugs in PHP's core, not in an application
Both flaws sit in PHP itself, so they affect every application on a vulnerable PHP, from WordPress to a script written in-house. Both can turn crafted requests from anyone, with no login, into code running on the server as the web server's user. PHP rates both 9.2 out of 10.
CVE-2026-109618: out-of-memory corruption
When an allocation fails, PHP jumps out of the request at once. If that happens while some of the request's memory is not yet set up, the cleanup afterwards can use invalid memory. PHP's advisory says several multipart parsing problems and application inputs can run a request out of memory within PHP's limits. Confirmed: code execution over HTTP against mod_php with default limits; PHP-FPM is susceptible by source analysis.
CVE-2026-109619: stale global state
A PHP worker keeps some state between requests that points into the previous request's memory. If a fatal error such as a timeout interrupts the reset of that state, a later request can use the freed memory. Session upload progress handling is one of the paths. Confirmed: memory disclosure and code execution, with the confirmed case on PHP 8.5.
Every PHP that serves web requests
- Affected: PHP before 8.5.12, 8.4.27, 8.3.36 and 8.2.35, however it runs: mod_php, PHP-FPM, CGI, FrankenPHP or LiteSpeed.
- No official release for 8.1 and older. Those branches are no longer supported. PHP's security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves; everyone else should move to a supported branch.
- Linux distributions often fix PHP under their own version numbers. Check your distribution's advisory rather than comparing version numbers with php.net.
Update, restart, then harden
PHP is clear that updating is the only complete fix. In order:
1. Check the PHP your website runs
php -v shows the command-line PHP, which can differ from the one your web server uses. Check the PHP-FPM version (for example php-fpm8.3 -v) or your hosting panel, and do it for every website and server.
2. Update and restart every worker
Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's fixed package, then restart PHP-FPM, Apache or whatever runs PHP. Workers that keep running keep the old code.
3. Turn off upload progress if you do not use it
PHP recommends session.upload_progress.enabled=0, set by the administrator, even after updating if nothing needs the feature. On PHP 8.5 that cannot update yet, it also recommends fatal_error_backtraces=0. Restart every worker after either change.
4. Keep multipart requests small, or off
PHP's advisory recommends a conservative post_max_size, a lower max_input_nesting_level, limits on input variables, multipart parts, per-part headers and uploads, and blocking multipart requests at the frontend where the application never takes them. It warns not to use RLIMIT_AS or RLIMIT_DATA as a fix: they trigger the vulnerable path.
Two rules, before and after the fix
21 October, 07:49 UTC. Five hours and 44 minutes before PHP's advisory, an emergency signature went live on every website on Shieldify with the WAF on. It refuses requests on the attack path that every proof of concept we reviewed from the leak used, before they reach the website.
21 October, 23:15 UTC. Once PHP's advisory was out, we added the limits on multipart requests that it recommends for the frontend, for every website with the WAF on.
Since they went live, the rules have refused requests carrying the leaked attack at our edge, before they reached the websites behind it.
Both rules are listed under Shieldify Emergency Signatures in each website's WAF settings and can be switched off per website, for an application that really needs what they refuse.
A firewall buys time. It does not fix PHP.
A web application firewall sees requests, not the memory inside your server. It can refuse the shapes of request that are known to trigger a flaw, and our rules did that within hours. But PHP's advisory names more ways in: application inputs that run a request out of memory, timeouts that interrupt a worker at the wrong moment. No rule can tell all of those apart from ordinary traffic.
So treat any WAF protection, ours included, as the time it gives you to update. Update PHP, restart the workers, and turn off what you do not use.
Sources
- PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618, RCE via OOM corruption).
- PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, RCE via stale global state).
- The PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements on php.net, 21 October 2026.
- Huntress, php2shell, leaked critical PHP vulnerabilities: the leak and the supported branches.
- Tanium, responding to CVE-2026-109618 and CVE-2026-109619: the timeline and watchTowr's exploitation report.
Times are in UTC. Shieldify's times are from our own records.