al-ice.ai

Patched on Tuesday, Unpatched on Friday: PHP’s CVE-2026-115560 Ships as a Config Change and Nothing Else

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Two days after the emergency PHP2Shell releases, php.net published a third remote-code-execution issue — and did not patch it. The 23 October 2026 front-page notice, headed “Informational advisory: Session upload progress,” assigns CVE-2026-115560 and asks administrators to set session.upload_progress.enabled=0 “until the next regular bugfix release, to fully protect from an unlikely RCE vector.” There is no new release. There is, as of our check today, no NVD record and no GitHub advisory. The entire machine-readable footprint of this vulnerability is one paragraph of prose on a project homepage.

That is a deliberate choice, and the advisory explains it: the PHP team judges the preconditions unlikely enough to handle “in the regular release cycle,” promising “a full advisory for CVE-2026-115560 with the next release.” The judgement is defensible. The gap it leaves in your tooling is the story.

What actually has to be true

The advisory is unusually precise about the preconditions, and they are narrow. All three must hold:

  • The application sets session.serialize_handler to php_binary or php_serialize in its configuration;
  • it then switches that handler to php at runtime with ini_set(), before calling session_start();
  • session upload progress is still enabled (the default).

php.net states the consequence plainly: “Applications that never change the serialize handler at runtime can keep the feature enabled.” This is not a pre-auth internet-wide condition like the two flaws patched on 21 October. It is a configuration-plus-code pattern that most applications never exhibit — and that a minority exhibit without ever having thought about it, because the runtime ini_set() was added years ago to make one legacy session payload readable.

The honest framing: this is a narrow vulnerability, not a low-impact one. The advisory calls it an RCE vector. If you match the pattern, the ceiling is the same ceiling as the flaws that triggered the emergency release.

You may already be protected — and that is the actual news

The sharpest line in the notice is the one that points backwards. The session.upload_progress.enabled=0 setting, php.net says, “was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026. If you applied it then, keep it in place and no further action is needed.”

We read that advisory directly. GHSA-6wmf-4rv5-p3rp — the php-src advisory for CVE-2026-109619, “RCE via stale global state,” rated critical, published 21 October 2026 at 13:34:13Z, with fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 — carries exactly that instruction under Mitigation: “For the session lifecycle case, set session.upload_progress.enabled=0 administratively and restart every worker. This prevents the demonstrated early session producing and consuming operations.”

It also carries a sentence that reads very differently today than it did on Tuesday: “It might be prudent to set session.upload_progress.enabled=0 if you don't need this feature even after applying the patch, as more attackers try to find flaws in this hardly-used and hardly-tested feature.”

Forty-eight hours later, a fresh CVE in that same hardly-tested feature. The advisory's speculative hedge became an accurate forecast within two days. That is our reading, not a vendor statement — but the sequence is on the record, timestamped, from the project itself.

Why the missing records matter more than the bug

We queried the NVD 2.0 API for CVE-2026-115560 on 23 October and got totalResults: 0. The php-src repository advisory list returns GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) from 21 October, and nothing for 115560. So:

  • No scanner will flag this. There is no version range to match, because there is no fixed version. SCA and vulnerability-management tooling keyed to NVD or GHSA has nothing to ingest.
  • No version bump will fix it. Every currently supported PHP release — including 8.5.12, shipped two days ago — is affected. Patching PHP2Shell did not patch this.
  • The only control is configuration. Which means the only way to know your exposure is to read your own php.ini and grep your own codebase, not to run a scan.

This is the same structural failure we traced in the Brotli CVE-2026-111497 briefing, where the only machine-readable claim that a library version was dangerous lived in free text in a GitHub release body. Here the free text is on php.net's homepage. Different project, identical consequence: a real vulnerability that exists in the human-readable record and is invisible to the automated one.

What to do

  • Set session.upload_progress.enabled=0 administratively and restart every worker — unless you actively use the upload-progress feature. This is php.net's instruction, it costs nothing on the overwhelming majority of estates, and it closes both this vector and the session path of CVE-2026-109619.
  • Grep for the actual pattern before deciding you are safe. Search your application for ini_set calls touching session.serialize_handler, and check whether your configured handler is php_binary or php_serialize. If both are true and upload progress is on, you match — and the mitigation is not optional.
  • Do not treat this as a reason to defer the 21 October patches. CVE-2026-109618 and CVE-2026-109619 are the pre-auth, broadly reachable flaws with confirmed exploitation attempts; 115560 is narrow. Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 first, then apply the config change on top. The GHSA is explicit that updating is “the only reliable mitigation” for the stale-state class and that no generic configuration mitigation covers every path.
  • Track this one manually until the next bugfix release. Because there is no NVD or GHSA record, it will not appear in your vulnerability queue. Put a calendar item against the next PHP bugfix cycle, when php.net says the full advisory lands.
  • Treat “hardly-used and hardly-tested” as an inventory category. The project named upload progress as a soft spot on Tuesday and produced a CVE in it on Friday. Default-enabled features that nobody exercises are where the next one comes from too; disabling what you do not use is cheaper than tracking what you do not need.

Verification note: the 23 October informational advisory — its heading, the session.upload_progress.enabled=0 recommendation, the CVE-2026-115560 identifier, the three stated preconditions (session.serialize_handler set to php_binary or php_serialize, switched to php via ini_set() before session_start(), upload progress enabled), the “unlikely RCE vector” and “applications that never change the serialize handler at runtime can keep the feature enabled” statements, the back-reference to GHSA-6wmf-4rv5-p3rp and the promise of a full advisory with the next release — were read first-hand from php.net on 23 October 2026. GHSA-6wmf-4rv5-p3rp's identifier, CVE mapping, critical severity, 2026-10-21T13:34:13Z publication timestamp, affected and patched version ranges, and the quoted Mitigation text including both the upload-progress instruction and the “hardly-used and hardly-tested” sentence were retrieved directly from the GitHub advisories API for php/php-src on the same day. The absence of an NVD record was confirmed by a direct NVD 2.0 API lookup for CVE-2026-115560 returning zero results, and the absence of a GHSA by the same php-src advisory listing. The reading that the 21 October forecast was borne out within two days is our analysis, not a project statement. We wrote and ran no exploit, sent no request to any third-party system, and tested no PHP deployment other than reading public advisory text.

Sources: