PHP Flags New Unpatched RCE Just Two Days After Emergency PHP2Shell Fixes
Barely 48 hours after shipping emergency patches for the critical PHP2Shell vulnerabilities, the PHP project is once again asking administrators to pay attention to a remote code execution (RCE) risk — though this time the maintainers are deliberately holding back from issuing a rushed fix.
The new issue, tracked as CVE-2026-115560, describes yet another path by which an attacker could execute code on a web server running PHP. According to the original report from The Hacker News, the project has classified the flaw as an unlikely risk because it only manifests in web applications configured in an unusual way. Rather than cutting another emergency release, the maintainers are recommending that affected operators disable a specific feature to close off the attack path.
Context: the PHP2Shell scramble
The disclosure lands at an awkward moment. The PHP2Shell flaws were serious enough to trigger an out-of-band patch cycle — the kind of release maintainers only push when the risk of waiting for the normal schedule outweighs the disruption of an emergency update. That the project is now publicly acknowledging a second, unpatched RCE vector just two days later speaks to how much scrutiny the codebase is under, and how quickly researchers are probing the areas around the freshly patched code.
It also illustrates a familiar pattern in vulnerability response: emergency patches often draw a wave of follow-on research as security teams and attackers alike examine adjacent code paths for similar weaknesses.
Why PHP is not rushing a fix
The distinction here matters. Not every RCE disclosure is a drop-everything event, and PHP's assessment is that CVE-2026-115560 requires a non-standard configuration to be exploitable. In practice, that means the population of exposed systems is likely small, and the project has judged that a hasty patch carries more risk — of regressions, of breaking legitimate deployments — than a documented workaround.
That reasoning is defensible, but it puts the burden squarely on operators. A vulnerability that is "unlikely" in the aggregate can still be very real for the specific organisations running the unusual configuration in question. Administrators should treat the advisory as a prompt to audit their PHP deployments rather than as noise to be ignored.
Recommended actions for defenders
- Review the advisory and confirm your configuration. Determine whether your applications rely on the feature PHP has flagged. If they do not, the exposure is largely theoretical for you.
- Disable the affected feature where it is not operationally required. PHP's guidance is explicit on this point, and turning the feature off is the recommended mitigation until a permanent fix lands.
- Apply the PHP2Shell emergency patches if you have not already. The earlier fixes remain the priority; the new disclosure does not diminish the urgency of closing the original flaws.
- Inventory internet-facing PHP applications, including those tucked away in internal tooling, legacy admin panels, and forgotten staging environments. Unusual configurations tend to survive longest in exactly those places.
- Watch for follow-up advisories. With the codebase under active scrutiny, further disclosures around this area are plausible.
The bigger picture
The back-to-back disclosures are a reminder that patch management is not a one-and-done exercise. Emergency releases frequently mark the beginning of a period of heightened attention on a project, not the end of it. For PHP — a runtime underpinning a huge share of the web — even a narrow, configuration-dependent RCE deserves a place on the risk register.
Defenders should also resist the temptation to read "unlikely risk" as "no action required." The maintainers' judgement is about aggregate probability, not about your specific environment. A short configuration review now is considerably cheaper than an incident response later.
We will update this article as PHP publishes further details or adjusts its guidance on CVE-2026-115560.
