Viral 'unpatched PHP RCE' claim debunked: CVE-2026-115560 needs rare runtime serializer switch

What circulated versus what php.net published

A widely reshared alert this week claimed PHP had warned of an unpatched remote code execution flaw just two days after shipping emergency patches, affecting unusual session configurations and carrying urgent mitigation guidance. According to a dev.to analysis published October 23, every element of that summary misstates the advisory php.net issued the same day.

The real advisory, as reported by dev.to, is informational rather than an emergency warning. It recommends turning off session upload progress — setting session.upload_progress.enabled to 0 — until the next regular bugfix release, in order to close off an RCE vector PHP considers improbable in real deployments. Crucially, that same setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619, published on October 21. Anyone who applied it then has nothing further to do.

The gap between the two versions is stark: an informational note became an unpatched RCE, a scheduled bugfix became urgency, and a precisely described rare configuration became a vague phrase suggesting broad exposure.

The conditions the vulnerability actually requires

Per the php.net advisory quoted by dev.to, the flaw can only occur under a specific combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration, then switch it to php at runtime via ini_set() before calling session_start(), while session upload progress remains enabled. Applications that never change the serialize handler at runtime are not affected and can keep the feature turned on.

Because this setup is rare, PHP is handling the issue in the normal release cycle and will publish the full advisory for CVE-2026-115560 alongside the next release.

How the bug likely works

The dev.to author offers a mechanism, explicitly flagged as interpretation pending the official advisory. Session data written under one serializer's encoding rules is later parsed under another; php_binary and php_serialize encode keys differently from the default php handler, so bytes written under one grammar get read under another. The upload-progress entry conveniently contains a key name chosen by the attacker. Serializer confusion over attacker-influenced session content is a classic route to code execution, though the exact primitive will only be confirmed when the full advisory ships.

Working out whether you are affected

The dev.to post reduces the advisory to three cases:

• If you disabled upload progress on October 21 as part of the earlier mitigation, you are already protected against this vector as well.
• If upload progress is on but your code never calls ini_set() on the serialize handler, the vulnerable combination does not exist in your deployment and you can leave the feature enabled — though you should still apply the October 21 patches (8.5.12, 8.4.27, 8.3.36 and 8.2.35, per the post) if you have not.
• If your application does switch serialize handlers at runtime — some frameworks and session shims have historically done so — disable upload progress now and watch for the full advisory.

The post also supplies a short checklist: search configuration and code for session.serialize_handler, search for ini_set calls touching the handler, and inspect the effective settings. A hit on the runtime switch marks you as the audience for the mitigation.

One operational trap deserves emphasis: the CLI and php-fpm routinely read different ini files, so verifying the setting via php -i at a shell proves nothing about the web server's view. Check through a phpinfo() page or php-fpm -i instead, since the likeliest failure mode is a mitigation applied to the wrong configuration file while FPM pools still run with progress enabled.

Why it matters

The dev.to post frames this as the week's fourth amplification story, alongside a LiteLLM supply-chain report reposted with scrambled dates, a ZDI private queue leaking onto a public mailing list, and a certificate authority complaining its issue was blown out of proportion. The shared pattern: reposting is cheaper than reading, and each step from the primary source sheds accuracy and adds urgency.

The php.net advisory is the counterexample — a precise trigger condition, an honest likelihood estimate, and the rarest sentence in disclosure: if you already did the thing, do nothing. For operators, the correct response to most alerts is no action, and only the primary source will tell you so.