PHP Warns of Separate Code-Execution Flaw That October 21 Patches Do Not Fix, Offers No Emergency Update

Since PHP shipped emergency patches on October 21 for the two critical PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, the project has now disclosed a third, separate problem that those patches do not touch.

The new issue is tracked as CVE-2026-115560. PHP published a short informational advisory about it today, October 23. It describes another way an attacker could run code on a web server.

PHP is not rushing a fix. The project says the flaw affects only web applications configured in an unusual way and considers it an unlikely risk. A full advisory will come with the next routine release.

What has to be true for an app to be exposed

PHP says three things must all happen in the same application:

• It sets the `session.serialize_handler` option to `php_binary` or `php_serialize` in its configuration.
• It then switches that option to `php` while running, by calling `ini_set()`.
• It makes that switch before it calls `session_start()`.

Session upload progress must also still be enabled. An application that never changes the serialize handler at runtime can leave the feature on and is not exposed through this path, according to PHP.

That is a narrow setup. PHP itself says it is unlikely in practice.

The one-line mitigation

PHP recommends setting `session.upload_progress.enabled=0` until the next routine bugfix release. The feature is on by default. It lets an application track the progress of a file upload.

This is the same setting PHP already listed on October 21 as a mitigation for CVE-2026-109619. Administrators who applied it then and left it in place need to do nothing more for the new issue.

Administrators who patched to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and stopped there are not covered if their applications fit the configuration above. The new bug is not fixed by those releases.

What PHP has not said

PHP has not stated which versions are affected or which release will carry the fix. It has not published a severity score. It has also not said whether the new issue shares a root cause with CVE-2026-109619.

No exploitation of CVE-2026-115560 has been reported. The attacks logged since October 21 target the two earlier PHP2Shell flaws.

Where the original PHP2Shell attacks stand

The first two flaws are a different story. Wiz Research reported them to PHP on August 24. Technical details leaked on October 20, and PHP moved its release up a day, to October 21 at 14:00 UTC. Both flaws carry a CVSS v4.0 score of 9.2.

Amazon Threat Intelligence said its MadPot honeypot logged an exploitation attempt on October 17, four days before the embargo lifted. Amazon said it remains unclear how the actor got exploit information that early. Its telemetry showed more proof-of-concept exploits on October 21 beginning around 02:00 UTC, hours before the patches.

Cloudflare said attempts against the flaws grew from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22.

Sophos and Arctic Wolf said attackers have tried to use the flaws to install a variant of the Mirai botnet. Previdian, Wordfence and others report scanning and probing but no confirmed code execution so far.

The patching problem is bigger than one bug

Analysis of W3Techs data for October 21 shows PHP running on 69.3% of websites where the server-side language can be identified. Socket calculated that roughly 48.5% of those PHP sites sit on branches that no longer get routine security updates from the PHP project. That is a calculation from version shares, not a count of vulnerable servers. Some of those installations get backports from Linux distributions or long-term-support vendors.

PHP's own advisory says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php highest, where an unauthenticated request can trigger a demonstrated exploit before any application code runs.

The NSA recommended taking affected systems offline until they can be fully mitigated. CERT-EU urged organizations that cannot patch to consider isolating their applications from public networks.

The University of Toronto's security office told its community to patch internet-facing systems, restart PHP so the fix actually loads, and treat any internet-facing system left unpatched from October 20 onward as potentially compromised until checked. Patching does not remove anything already installed.

What comes next

PHP says the full CVE-2026-115560 advisory will arrive with the next routine release. It has not given a date. Until then, the session upload progress setting is the only guidance on the table, and whether this bug traces back to the same defect as CVE-2026-109619 is an open question.