session.upload_progress.enabled=0 as a stopgap, not a fix.
On October 21 the PHP security team announced an emergency release for two critical flaws. Both let an unauthenticated attacker run code on a server, and both score 9.2 on the CVSS v4 scale. If PHP runs anywhere you care about, even on a box you forgot about, this one is worth ten minutes today.
This is a heads-up for readers, not an incident report. Nothing here is about our own systems. We read the advisory so you do not have to, and we pulled out what matters.
What happened, and who is affected
The first bug, CVE-2026-109618, comes from out-of-memory handling: PHP can be interrupted while request data is only partly set up, and cleanup may then treat invalid data as valid. The second, CVE-2026-109619, is stale global state: memory that belonged to one request is freed, but a pointer to it survives and a later request on the same worker can use it. Neither needs a login.
If PHP serves web requests, assume you are in scope. PHP's advisory names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, and it rates mod_php the highest because a demonstrated exploit runs before any application code does. That covers WordPress, Drupal, and Laravel sites, but also the leftover admin panel and the vendor appliance with PHP inside. Earlier builds of PHP 8.6.0 are affected too.
Fix it today
Check what you run with php -v, then move to a fixed release: 8.5.12, 8.4.27,
8.3.36, or 8.2.35. PHP 8.1 and older no longer get updates from the project, so ask your
distribution or long-term support vendor about backports. The security team also published
minimal source backports for 7.4, 8.0, and 8.1, but moving to a supported branch is the better
answer. After upgrading, restart your workers (FPM, Apache, or whatever serves PHP) so the old
code is not still running.
Do not forget the PHP you did not install yourself. Shared hosting, containers built a year ago, and CMS plugins that bundle a runtime all count, so check every system, including servers where third-party software uses PHP even if your own sites do not. Rebuild old container images instead of patching them in place.
If you cannot patch yet
PHP lists stopgaps that block specific paths. They do not make an installation safe, so treat
them as a bridge to the update. The most widely applicable ones: set
session.upload_progress.enabled=0 in php.ini, your FPM pool, or server
config and restart every worker (not through ini_set() or .user.ini),
set a low post_max_size with upload_max_filesize below it, enforce
request size and field limits at your web server or proxy, and on PHP 8.5 set
fatal_error_backtraces=0. Read the full advisory before changing production, because
a couple of the mitigations interact.
Public proof-of-concept exploits now exist. Rapid7, a US security firm, says they are tied to specific OS, PHP version, and web server combinations and that none appears broadly reliable, and that it has not observed exploitation in the wild but has seen multiple reports of attempts. Sophos reports scanning and a small number of failed attempts, with no confirmed compromise. Both expect that to change, so treat patching as urgent and recheck the advisory for updates. A separate issue, CVE-2026-115560, led PHP to recommend keeping the upload-progress setting off until the next bugfix release.
Want the exploit explained?
If you would rather watch than read, one of our favorite YouTubers, SomeOrdinaryGamers, does a good breakdown of the exploit in The PHP Hack Situation Is Insane... It is a friendly way to see why this one has people moving fast. He has also posted a newer follow-up, It Just Keep Getting More Insane..., and the channel is worth a follow for security news explained in plain language.
Sources and the official word: PHP's security advisory and the Rapid7's analysis.