23 Oct: attack reports and PHP advisory

A second PHP advisory, with a narrower trigger

Two days after the emergency PHP2Shell releases, PHP published an informational advisory for a separate issue, CVE-2026-115560. The advisory does not describe a general PHP2Shell bypass. It describes an unusual configuration path: an application must set session.serialize_handler to php_binary or php_serialize, then change it to php at runtime with ini_set() before calling session_start(). Session upload progress must also remain enabled.

PHP’s control is one setting: session.upload_progress.enabled=0. That is the same control the PHP2Shell advisory for CVE-2026-109619 already listed. PHP says administrators who applied it on 21 October should keep it in place and need no further action for this issue. Applications that never change the serialize handler at runtime do not meet the published condition.

The advisory is deliberately incomplete. PHP has not named affected versions, a fixed release or a severity score. It says a full advisory will be published with the next regular bugfix release. The issue is not fixed by 8.2.35, 8.3.36, 8.4.27 or 8.5.12, and it does not replace the need to install those releases. The vulnerability record keeps those gaps visible.

Millions of attempts is not millions of compromises

Security Affairs, citing Censys, reported more than 34.4 million internet-facing PHP services still on vulnerable versions on 23 October. The figure is a service count, not a count of organisations or confirmed victims. A distribution backport can also carry a fix without changing the version string that a scanner sees, so exposure estimates need to be read as estimates rather than an inventory of compromised sites.

The same reporting repeats Cloudflare’s attack figures: thousands of attempts in the ten hours before disclosure, tens of thousands within 45 minutes, hundreds of thousands within two hours and millions by 22 October. Those are requests, not successful shells. The reports reviewed for this update did not identify a confirmed successful real-world remote code execution, and described observed traffic as mainly scanning, fingerprinting and attempted botnet delivery. That is a limit of the reporting reviewed, not a claim that no attack anywhere succeeded.

Security Affairs also reported two vendor findings. VulnCheck built a working exploit that chains both PHP2Shell flaws and uses a memory leak to bypass ASLR, but found no evidence of widespread use. The same report said Sophos observed an attempted delivery of a likely Mirai variant called Potassium that failed, and that Arctic Wolf found ENS-based command-and-control capability in the samples but inactive.

Why this matters for the patch decision

A working exploit in a laboratory and a compromised production site are different evidence states. So are a million probes and a million victims. The practical response does not change: patch the runtime, restart every PHP worker, and verify the version the serving process actually loads. The dossier keeps the fixed releases and affected branches in one place.

The new advisory adds one narrow configuration check. If the application never switches session.serialize_handler at runtime, the published CVE-2026-115560 condition does not apply. If it does, disabling session upload progress is the stated control until the regular release arrives. The mitigation guide explains why such settings are interim controls, not substitutes for the upstream fix.

CISA’s KEV catalog version 2026.10.21 still listed neither PHP2Shell CVE when checked on 23 October. That remains a catalog observation, not proof that exploitation never happened. The sources page records the check time and the separate editorial cut-off.