On Wednesday we told you that a critical flaw in PHP had been fixed, that our platform and managed services were already patched, and that there was nothing for most of our customers to do. All of that still holds. But the PHP project has since published a follow-up, and because that first article promised we would keep an eye on this, here is the quieter second instalment, which for almost everybody reading is reassuring rather than alarming.
What the new advisory actually says
On 23rd October 2026, two days after the security releases, the PHP project published a short notice it calls an informational advisory. Its recommendation is a single line: set one configuration option, session.upload_progress.enabled=0, and leave it off until the next ordinary bugfix release of PHP arrives.[1] A configuration option is simply a setting, a switch in a file that tells PHP how to behave, as distinct from the fix on Tuesday, which was new code.
The project has given the issue the tracking identifier CVE-2026-115560 and says the full write-up will follow with its next release.[1] As of this article, no later bugfix release has shipped, so the advice remains the setting rather than an update.
The condition that matters, and why most sites are fine
Here is the part the louder coverage left out, and it is the whole story. The advisory is clear that this only matters under an unusual and deliberate combination. For a site to be affected, its application has to set PHP’s session.serialize_handler option to one of two particular values, and then deliberately switch it to a third value, php, while the site is actually running, using ini_set() before a session begins.[1]
That is not something an ordinary WordPress site does, or would ever have a reason to do. It is a specific piece of behaviour an application has to go out of its way to perform. So while it is true, as some write-ups said, that this touches fully patched versions of PHP, leaving out the condition gives a misleading impression. “Affects every version” and “affects your website” are different sentences, and the gap between them is the single most useful thing to understand when you read a security headline. The question worth asking, every time, is: what has to be true for this to reach me?
A note on reading the news
Some of the coverage this week dropped that condition, and at least one write-up managed to contradict itself on the same page about whether a fix even exists. We are not interested in naming anyone; the point is simply that the project’s own advisory is the thing to read, and it is calm, specific and honest about how narrow this is. A firewall at the network layer can also block known bad request patterns quickly, which buys a little time, but it is not a substitute for the setting or, eventually, the update, and nobody should treat it as one.
What, if anything, you need to do
If we host and manage your site, nothing. These two items arrived three days apart, one loud and one quiet, and reading both so that the right thing happens on your behalf is exactly the job you are paying a managed platform to do. If you run your own server, read the PHP project’s advisory, check whether your application does the configuration juggling described above, which it almost certainly does not, and apply the setting if it does.
Tuesday’s fix had a nickname and a warning from the national cyber authority. Friday’s is one line in a configuration file that most sites never needed. They are the same unglamorous job, done at different volumes, and keeping up with both of them, quiet one included, is the whole point.
Related reading
- A critical PHP security update landed this week, and if we manage your hosting it is already done
- Your host will tell you a PHP upgrade makes your site faster, and the benchmarks disagree
Sources
- Informational advisory: Session upload progress, the PHP project, 23rd October 2026.
