PHP2Shell Isn't Over

On October 21, PHP shipped an emergency release to fix the two critical remote-code-execution flaws known as PHP2Shell. That part worked. Sites that applied the update closed those two holes. The story did not end there, and anyone who moved on afterward is now behind.

On October 23, PHP disclosed a third remote code execution path, CVE-2026-115560, in the session upload progress feature. The October 21 release does not fix it. There is no patched version yet, and PHP's interim guidance is to disable the feature (session.upload_progress.enabled=0) until the next release ships.

Three issues, one patch window

The confusion this week comes from treating these as one event. They are three. The original PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, were patched on October 21. A separate crash regression in SimpleXML, tracked as GH-24488, slipped into two of those releases and has since been fixed in source; it is an availability bug, not a break-in, and reverting the security patch to avoid it would be a mistake. The one that still needs attention is CVE-2026-115560.

The question that actually matters: how far does it reach

PHP describes CVE-2026-115560 as narrow. By their account, a site is only exposed if it uses a non-default setting for how PHP stores session data and then switches that setting at runtime, with upload progress enabled. On that reading, few sites are affected, and PHP calls exploitation unlikely.

Security researchers have begun questioning whether the affected population is larger than that description, pointing to common server configurations as a route by which the same conditions could arise without an application changing anything in its own code. If that holds, the exposed set would be considerably wider than the advisory implies, reaching ordinary shared hosting of the kind most small-business sites run on.

RedEye is not asserting that today. We are actively investigating the real reach of CVE-2026-115560, and we are doing it through coordinated disclosure with the PHP security team rather than in public. We will publish a definitive assessment once it is validated, and we will not share exploit detail. We would rather be right than loud.

We are not done with this one

We did not come to CVE-2026-115560 from the sidelines. We have been working with a researcher who took it apart, and what we are validating now points somewhere a good deal more interesting than "unlikely." We are not going to spoil it before it is confirmed and responsibly disclosed; the people running PHP tonight deserve that much. But watch this space. Part two is coming, and we think you are going to want to be here for it.