Two days after PHP shipped emergency fixes for the PHP2Shell vulnerabilities, the project has disclosed a third way an attacker could run code on a PHP server. This time, there is no emergency release. The interim fix is a configuration setting that, earlier in the week, was widely described as only a partial defense.
PHP published a short informational advisory on October 23 for CVE-2026-115560, a code execution issue that the October 21 releases (PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35) do not fix. As SecureWorld News reported earlier, those releases closed CVE-2026-109618 and CVE-2026-109619, the two critical engine flaws that prompted the NSA to tell organizations to patch or pull systems offline.
The new flaw is far narrower than its predecessors. But its arrival, together with what the PHP Foundation has since disclosed about why the original bugs went unfixed for so long, suggests security teams should treat PHP2Shell as an ongoing incident rather than a closed ticket.
CVE-2026-115560 requires a specific combination of configuration and application code. According to PHP, an application must set session.serialize_handler to php_binary or php_serialize in its configuration, then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime are not exposed through this path.
PHP describes the setup as "unlikely in practice," which is why it is handling the fix in its regular release cycle and will publish a full advisory alongside that release. Several things remain unknown. PHP has not said which versions are affected, which release will carry the fix, what severity score the flaw will receive, or whether it shares a root cause with CVE-2026-109619. No one has reported exploiting the new flaw. The attacks observed since October 21 target the two earlier vulnerabilities.
Because the trigger depends on application code as well as server configuration, a quick way to rule out exposure is to search codebases, including third-party plugins and frameworks, for runtime changes to session.serialize_handler.
PHP's recommendation until the fix ships is a single line: set session.upload_progress.enabled=0.
Defenders will recognize the setting. It circulated widely as a stopgap before Wednesday's release, and PHP's advisory for CVE-2026-109619 listed it as a mitigation for that flaw. It never covered the other one. PHP's October 21 release announcement made it clear that updating was the only complete protection, and practitioners cautioned against treating the setting as anything more than a partial measure.
That guidance still holds. For the two critical flaws, patching remains the only real fix. What has changed is that the same setting is now PHP's primary interim control for a third flaw. PHP says organizations that applied it earlier should keep it in place and need to do nothing more.
The risk is with teams that treated the setting as a bridge to the patch and reverted it after upgrading, often to restore upload progress bars. Those teams should turn it off again. The cost is small: the feature only tracks how far an upload has progressed, so disabling it affects progress indicators, not the uploads themselves.
The researchers behind PHP2Shell signaled early that this would not be a one-patch problem. In its technical write-up, Wiz Research said it initially reported four issues to PHP but came to see the vulnerability as deeply rooted in the codebase, requiring a comprehensive fix rather than spot repairs.
The PHP Foundation's postmortem, published alongside Wednesday's release, explains how the flaw got that deep. Part of the problem traces to an out-of-memory issue first noticed during PHP's first external security audit in 2024. The security team drafted several competing fixes, each with real drawbacks: breaking backward compatibility, introducing new denial-of-service potential, or requiring changes across third-party extensions that seemed impossible to coordinate. Working by consensus, without a known path to remote code execution, and relying on a handful of developers with deep engine knowledge, the team saw the work stall and restart for months.
The Foundation did not soften its assessment. The delay, it wrote, "was a structural failure, caused by both the security team's decision process and its lack of resources." The security team is now changing its process so decisions can be made by majority vote, and the Foundation is asking organizations that depend on PHP to help fund its security work.
Outside pressure broke the stalemate. Calif, OpenAI, and Wiz reported related issues in August, including a remote code execution path tied to the same root cause; OpenAI also independently identified that root cause. Wiz found its first vulnerability on August 19 using its own Wiz Atlas agent alongside Gemini 4 Argon and GPT-5.6 Sol. Trail of Bits has since been auditing PHP too.
That combination is why more findings are likely. Several well-resourced teams, many of them using AI tooling, are now examining the same session handling and request startup code. Every patch also hands both researchers and attackers a diff to study. Log4Shell followed the same pattern. Apache's first fix in December 2021 was followed within weeks by CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832 as researchers worked through adjacent code paths. Not every follow-on was critical, and PHP's own assessment of CVE-2026-115560 suggests this one may not be either. The broader lesson is that a first fix tends to open a new round of scrutiny rather than close the case.
There is also a dependency lesson for security leaders. A language underpinning government services, commerce, and banking has its core security work resting on a small group of funded developers and volunteers. That is a supply chain risk in its own right, separate from any single CVE.
The picture on the two critical flaws has sharpened but not resolved. Amazon Threat Intelligence reported that attempts to exploit PHP2Shell began four days before the patches were released, with varied payloads and anonymization infrastructure that point to multiple actors. Amazon says it is unclear whether any of those attempts succeeded.
Dataminr's TRACE team reported Thursday that observed activity remains limited to scanning, fingerprinting, and non-working exploits, with no known compromises, though it expects working exploits to emerge. PHP Foundation Executive Director Elizabeth Barron told CNBC the Foundation had seen no "evidence of any working exploits." Meanwhile, VirusTotal estimates that more than 5.1 million PHP hosts are exposed online.
The gap between attempts and confirmed compromises is encouraging, but it is not proof of safety. The memory disclosure path researchers demonstrated can expose credentials without running code, which leaves little for traditional detection to find.
Start by confirming that the October 21 patches are actually running on every PHP runtime that serves web requests, not just installed. Keep session.upload_progress.enabled=0 in place, or reapply it anywhere it was reverted after patching, and check application code for runtime changes to the serialize handler. Credential rotation and runtime monitoring from the earlier guidance still apply to any internet-facing PHP server.
Then plan for what hasn't been released yet. PHP's next routine release will carry the fix for CVE-2026-115560 and a full advisory with affected versions and severity, so patch management teams should be ready to deploy it. They should also expect it may not be the last.
PHP2Shell started as two CVEs and a leaked disclosure. Two days later, it was three CVEs, a public admission of structural failure, and a codebase under more scrutiny than it has seen in years. The teams that do best will treat this as an ongoing incident rather than a patch they already applied.