PHP published an informational advisory on 23 October for CVE-2026-115560, a remote code execution issue in session handling. There is no patch. The fix is expected in the next regular bugfix release, and until then the project's advice is to set session.upload_progress.enabled to 0.

Anyone who read our first piece on PHP2Shell will notice that we said disabling session upload progress was not a workaround. That was correct then. The advice is correct now. Both can be true and it is worth explaining why, because the confusion is doing real damage.

Two different flaws, one setting

For CVE-2026-109618, the out-of-memory corruption, session upload progress is irrelevant. Disabling it did nothing, and advice circulating in the first days that implied otherwise sent people away with a false sense of having acted.

For CVE-2026-109619, the stale global state flaw, session upload progress was part of one attack path among several, so disabling it narrowed the exposure without closing the hole.

For CVE-2026-115560, the setting is the mitigation the project itself recommends, because the flaw runs through that code. Same toggle, three different relationships to three different bugs.

A mitigation is not a property of a setting. It is a property of a setting and a specific flaw together, which is why "disable session upload progress" is useless as standing advice and useful as advice about one CVE.

What the new flaw needs

PHP describes 3 conditions, all of which must hold at once. The application sets the session serialize handler to php_binary or php_serialize. It then switches the handler to php at runtime, with ini_set, before calling session_start. And session upload progress is still enabled.

The project's own assessment is that the combination is unlikely in practice. No CVSS score had been published when the advisory went out, and neither the CVE programme nor NVD had a record of it.

The part that is genuinely awkward

The flaw affects fully patched PHP, including 8.5.12, the release that fixed PHP2Shell on 21 October. So an administrator who did everything right last week — moved fast, took the outage, applied the emergency build — is still exposed to this one if their application happens to do that specific sequence. Not badly, on the project's own assessment, but the clean feeling of being patched is not available.

One more wrinkle worth knowing: at least one source warns against relying on ini_set inside the request to disable upload progress, because by then the processing may already have happened. Set it in the configuration.

Informational is a judgement, not a category

PHP did not ship an emergency release for this, and the reasoning is in the conditions: a combination the project assesses as unlikely does not justify pulling the whole ecosystem through another out-of-cycle build 2 days after the last one.

Defensible, and still a call. Informational means the project has told you and left the risk assessment with you, which only works if you can answer whether your own application changes the serialize handler at runtime. Most teams cannot answer that without going and looking, and most will not go and look.

What to do

  • Set session.upload_progress.enabled to 0 in php.ini, not in application code.
  • Check whether your application changes the session serialize handler at runtime. If it never does, you do not meet the conditions.
  • Do not treat this as a reason to delay the PHP2Shell patches if you somehow still have not applied them. Those flaws are the larger risk by a distance.
  • Watch for the next bugfix release, which is where the actual fix is expected.
  • If you wrote runbooks in the last week that say disabling upload progress mitigates PHP2Shell, correct them. That is the error this advisory will entrench if nobody does.

What is not established

  • The severity. No CVSS score was published with the advisory.
  • Whether anyone is exploiting it. Nothing has been reported.
  • How many applications meet all three conditions. PHP says the combination is unlikely and gives no estimate.
  • When the fix ships, beyond the next regular bugfix release.
  • Whether the scans that have been attributed to upload progress relate to this flaw or to the earlier ones. Reporting disagrees.

PHP's advisory was not retrieved directly for this piece; the conditions above are as the reporting of it describes them.