PHP's CVE-2026-115560 Is Not Fixed by the PHP2Shell Releases, and Has No Patch Date

Administrators who upgraded to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on or after Oct. 21 have not fixed CVE-2026-115560. PHP disclosed it on Oct. 23 as a separate flaw that can lead to code execution on a web server, but only where an application changes its session serialisation handler at runtime while upload progress tracking is still on. It has no CVSS score, no emergency release and no fix date.

What the advisory conditions are

Both conditions have to hold, according to Field Effect's summary of the PHP advisory. First, the application must call ini_set() to switch session.serialize_handler from php_binary or php_serialize to php before session_start(). Second, session.upload_progress.enabled must still be on, which is the setting the PHP2Shell guidance already tells operators to turn off.

The advisory does not give an affected version range, per Field Effect and Escudo Digital, and PHP considers exploitation unlikely in most installations. Escudo Digital reports that PHP has not reported any attacks actively exploiting it. No source this article read gives a proof of concept.

The fix will arrive in a future routine release, not an emergency one. That is the opposite of the PHP2Shell pair, where the project pre-announced the release on Oct. 20 and shipped the next day.

CVE	Status on Oct. 29	Fix
CVE-2026-109618	On CISA's KEV list since Oct. 26	8.5.12, 8.4.27, 8.3.36, 8.2.35
CVE-2026-109619	On CISA's KEV list since Oct. 26	Same releases
CVE-2026-115560	No score, no exploitation reported	Future routine release

Why people asked whether the fixes were incomplete

The mitigation for the new flaw is identical to one of the interim workarounds for CVE-2026-109619: set session.upload_progress.enabled=0 and restart PHP workers. That overlap led some people to ask whether the October 21 fixes fell short, Field Effect says. PHP's answer is that they did not. The October 21 releases and CVE-2026-115560 have different exploitation requirements, according to the advisory as Field Effect reports it.

BleepingComputer's exploitation report lists it as an unpatched related issue and repeats the same advice. Varonis, which documented the PHP2Shell root cause as stale engine-global pointers left behind when a request runs out of memory during session upload-progress handling, puts the same feature at the centre of the PHP2Shell chain.

What to do now

Three actions cover it, none of which needs a patch.

• Disable session.upload_progress.enabled. Escudo Digital notes this turns off progress tracking for uploads but not uploads themselves, so check whether any application reads that progress data first.
• Restart all PHP workers after the change;
• Search internally developed code for ini_set('session.serialize_handler', ...) calls that run before session_start(). That pattern is the second precondition, which is why Field Effect says to review it.

Operators who already applied the setting for CVE-2026-109619 need nothing further, Escudo Digital says. Managed hosting and SaaS customers should follow their provider's guidance, since they cannot change the runtime themselves.

The open question is when PHP's next routine release arrives. The advisory gives no date, so the workaround is the only control until it does. Compare the handling of a flaw with a similar shape: our report on the unpatched EDK II network-boot flaw, and on Oracle E-Business Suite probing.