Version strings first: 8.5.11, 8.4.26, 8.3.35, 8.2.34. Those are the releases a widely shared Medium advisory listed as carrying the fix for CVE-2026-109618 and CVE-2026-109619, a memory-safety flaw in the session upload progress code that it rated CVSS v4.0 9.2, reachable without authentication on default settings. The patch was due on 2026-10-21 at 14:00 UTC, a week before I'm writing this. Before you do anything else, check the official php.net changelog and your distro's security tracker against what's actually installed, because a blog post is a heads-up and an advisory is the source of truth.

session.upload_progress.enabled = Off

If you're on one of those builds, good. You've closed this particular hole. What bothers me is the step most of us will take next, which is quietly deleting the emergency line from php.ini because the incident ticket is closed and the line feels like scaffolding. I'd argue the opposite. The stopgap was the most useful change your servers got all month, and the upgrade only made it optional.

Ask yourself when you last shipped a feature that relied on session.upload_progress. I went through the four codebases I touch regularly, one of them a Laravel app that started life in 2016, and found zero reads of the progress key in the session. Our upload progress bars all come from the browser, where the XHR or fetch upload events report bytes sent without the server having to keep any state at all. Meanwhile the server-side feature has been enabled by default on every FPM pool, parsing every multipart request in case someone wanted it.

That's the real shape of this incident. Code that nobody calls still runs if a default switches it on, and code that runs can break. A framework or CMS bug can be patched in userland; a core bug like this one reaches WordPress, Drupal, your homegrown API and that forgotten internal tool equally, and the only lever you hold below the fix is configuration. Old branches make it worse: the advisory notes that 8.0, 8.1 and everything in 7.x and 5.x get nothing, so for those hosts turning the feature off is the whole defence rather than a stopgap.

Now the fair objection. Upload progress exists for a reason: it worked before browsers exposed upload events reliably, and some long-lived apps, especially ones with server-rendered admin panels and a polling endpoint, still depend on it. Flipping it off globally can silently break a progress bar some customer relies on, and nobody wants a security change that shows up as a support ticket at 23:40 on a Friday. There's also a reasonable case that the right fix is in core, and that ops teams shouldn't have to second-guess every default php-src ships.

Both points are true, and neither changes where I land. Breakage here is cheap to detect, because a grep for the progress session key across your repositories takes about a minute, and the apps that need it can turn it back on in their own pool config with a comment explaining why. That flips the burden: the feature has to justify being on, rather than you having to justify turning it off. As for core defaults, I'd happily see php-src reconsider this one, but changing a long-standing default is slow and careful work for good reasons, and your servers don't need to wait for that conversation to finish.

The same thinking goes for the other things that advisory suggested and you may have added in a panic: open_basedir per pool, a disable_functions list, alerts on FPM workers dying with signal 11. None of that stops a determined attacker, and the write-up says so itself. But a worker crash that shows up in your logs within minutes is the kind of early warning you rarely get, and a pool that can't see outside its own directory turns a bad night into a manageable one. Keep the boring defences once the excitement is over.

So here's what I'd really like to know from the comments: is anyone still running server-side session.upload_progress in production on purpose, and what would it take for you to move that progress bar to the client? If enough of us answer, maybe we've got the data to take to php-src about changing the default.