The 'BREAKING' unpatched PHP RCE that wasn't: what CVE-2026-115560 actually requires

The alert going around today: ‼️ BREAKING ‼️ PHP warns of another UNPATCHED RCE vulnerability just 2 days after releasing emergency patches. New "CVE-2026-115560" affects only unusual session configurations. PHP has issued urgent mitigation guidance. Three lines, each one a little wrong. The actual advisory — php.net, today, 300 words, measured — says: it's an informational advisory, handled in the regular release cycle, reachable only through a config combo PHP itself calls "unlikely in practice", and the mitigation is the same one from Tuesday — if you applied it then, "keep it in place and no further action is needed."

This is the third amplification story of the week on this blog, and the easiest to settle — because unlike LiteLLM's scrambled dates or eMudhra's "out of proportion" complaint, this one comes with a checklist you can run in three commands. By the end you'll know whether CVE-2026-115560 concerns you, and more usefully, how to read the next BREAKING without the exclamation marks.

What the advisory actually says

php.net, October 23, verbatim:

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. This setting 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.

The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

Count what changed between that text and the BREAKING version: "informational advisory" became "unpatched RCE"; "regular release cycle" became "urgent"; "unlikely in practice" became a vague "unusual session configurations" that reads like it could be you. None of the repost's three lines survives contact with the primary source.

The bug, in one paragraph

(Interpretation flagged as such — the full advisory ships with the next release.) The session store is written by one serializer and, after the runtime switch, parsed by another. php_binary and php_serialize have different key-encoding rules than the default php handler — so bytes written under one grammar get read under another, and the upload-progress entry conveniently contains an attacker-chosen key name. Serializer confusion on attacker-influenced session content is the classic path to code execution; the exact primitive waits for the full advisory. What PHP is telling you today is precisely who needs to care, which is the rarest and most useful sentence in vulnerability disclosure.

The decision tree

• You set session.upload_progress.enabled=0 on Tuesday (the php2shell mitigation, GHSA-6wmf-4rv5-p3rp): you're already protected from this vector too. Nothing to do.
• You kept upload progress on and your application never calls ini_set() on session.serialize_handler: keep the feature enabled — the combo doesn't exist on your fleet. Apply Tuesday's patches if you haven't (8.5.12, 8.4.27, 8.3.36, 8.2.35).
• You do switch serialize handlers at runtime (some frameworks and session shims have done this historically): set upload progress to 0 now, and watch for the full advisory with the next release.

The lab: three lines to know

# 1. Who configures the serialize handler at all?
grep -rn "session.serialize_handler" /etc/php* src/ config/ 2>/dev/null

# 2. Does any code switch it at RUNTIME? (this is the rare leg of the combo)
grep -rn "ini_set.*serialize_handler" src/ vendor/ --include='*.php' 2>/dev/null | grep -v tests

# 3. What is the effective config on this box?
php -i | grep -E 'session.serialize_handler|upload_progress.enabled'

Reading the output:

• Command 2 returns nothing → you're in "applications that never change the serialize handler", full stop. The advisory says you can keep upload progress on.
• Command 2 returns a hit → you're the fleet the advisory was written for: session.upload_progress.enabled=0 in your php.ini now, until the patched release.
• Command 3 shows upload_progress.enabled => On and you already turned it off — check you edited the right ini file (FPM pools and CLI routinely read different ones; php -i on the CLI proves nothing about php-fpm's view, repeat it through a phpinfo() page or php-fpm -i).

That last one is the trap I'd bet on: Tuesday's mitigation applied to the CLI config, the FPM pool still streaming uploads with progress enabled. The advisory is three hundred words; the operational reality is one ini file per SAPI.

Why this post exists

Look at the week: LiteLLM's supply-chain compromise got reposted with dates scrambled into the wrong month; ZDI's private queue leaked onto the public LKML; a CA chairman blamed "social media amplification" for scrutiny he'd priced wrong; and today, a measured informational advisory got dressed as a BREAKING RCE. Four different failure modes, one common denominator: the repost is cheaper than the read, and every step away from the primary source loses accuracy and gains urgency.

The skill this blog keeps coming back to is boring and decisive: open the advisory. php.net's text is the counterexample to its own amplification — no exclamation marks, an honest likelihood estimate ("unlikely in practice"), a precise trigger condition, and the sentence almost no disclosure ever contains: if you already did the thing, do nothing. That last sentence is why people should read sources: most days, the correct action is no action, and only the primary source will tell you so.

Sources: php.net — Informational advisory: Session upload progress (Oct 23, 2026) · GHSA-6wmf-4rv5-p3rp / CVE-2026-109619 advisory · Part 1 — the php2shell lab

TL;DR — CVE-2026-115560 is real but requires a serializer switched at runtime plus upload progress enabled; PHP calls it unlikely in practice and ships the fix next release. Tuesday's mitigation already covers you. Three grep commands above tell you which case you're in. The BREAKING version of this story is the case study; the advisory is the answer.