PHP's Whack-a-Mole Week: Third RCE Surfaces as PHP2Shell Exploitation Explodes

As reported by The Hacker News, PHP's security team disclosed a third remote code execution vulnerability this week — CVE-2026-115560 — arriving just 48 hours after the October 21 emergency release that patched the critical PHP2Shell flaws CVE-2026-109618 and CVE-2026-109619. While the new issue carries a narrower attack surface, the timing and accelerating exploitation of the original pair make this a moment that demands attention from every PHP shop.

The Vulnerability Landscape

Why CVE-2026-115560 Is Narrower but Not Negligible

The new flaw requires a specific and somewhat unusual configuration sequence: an application must set session.serialize_handler to php_binary or php_serialize in its configuration, then switch it to php at runtime via ini_set() before calling session_start() — all while session.upload_progress remains enabled. PHP itself considers this combination unlikely in practice, which is why the fix is deferred to the regular release cycle rather than triggering another emergency drop.

The mitigation is identical to what was already recommended for CVE-2026-109619: set session.upload_progress.enabled=0. If you applied that mitigation on October 21, you are already covered for the new issue — assuming you left it in place.

That said, "unlikely" is not "impossible." Frameworks that allow dynamic configuration overrides, custom session handlers, or middleware that manipulates PHP runtime settings could inadvertently create the conditions for exploitation. Large codebases with third-party plugins or legacy integrations are the most likely candidates to hit this pattern without realizing it.

The Real Story: PHP2Shell Exploitation Is Accelerating

The more pressing concern is the explosive rate of exploitation targeting the two patched PHP2Shell flaws. Amazon's honeypot infrastructure logged attempts on October 17 — four days before public disclosure — strongly suggesting pre-disclosure weaponization by threat actors with early access to exploit details. Cloudflare reported traffic scaling from tens of thousands of attempts within 45 minutes of the advisory to millions by the following day.

This pattern mirrors classic zero-day economics: once a proof-of-concept or technical advisory becomes public, mass scanning follows within hours. Any PHP deployment exposed to the internet that has not yet applied the October 21 patches should be treated as potentially compromised.

Who Is Most at Risk

Immediate Actions

1. Patch immediately if you have not already. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Versions prior to 8.2 are end-of-life and will not receive fixes — plan migration now.
2. Disable session upload progress as defense-in-depth: set session.upload_progress.enabled=0 in php.ini. This covers both CVE-2026-109619 and CVE-2026-115560.
3. Audit runtime configuration changes: search your codebase for any call to ini_set('session.serialize_handler', ...) combined with session_start(). If you find this pattern, treat the application as exposed to CVE-2026-115560.
4. Hunt for compromise: review web server access logs for unusual POST requests with session upload progress parameters, unexpected PHP process spawning, or outbound connections from your web server to unfamiliar IPs.
5. Deploy WAF rules targeting PHP2Shell exploitation patterns if your upstream provider has not already pushed signatures.

Shield53 Recommendations

Beyond the immediate patching imperative, this week's PHP chaos underscores a structural problem: PHP's session handling subsystem has now produced three critical or high-severity RCEs in rapid succession. Organizations should:

• Inventory every PHP application in your environment, including version, exposed surface, and session configuration — you cannot defend what you cannot enumerate
• Subscribe to PHP security advisories directly at php.net/security rather than relying on secondary reporting, which can lag hours behind official disclosure
• Implement runtime PHP configuration hardening as a baseline: disable unused features (session.upload_progress, expose_php=Off, allow_url_fopen=Off where feasible)
• Validate hosting provider patch SLAs — if your provider cannot confirm PHP patching within 24 hours of an emergency release, you need a contingency plan
• Assume active compromise for any internet-facing PHP server that was unpatched between October 17 and your patch deployment date — perform forensics, don't just patch and move on

Three RCEs in one subsystem in one week is not a coincidence — it is a signal that PHP's session handling deserves a security audit far deeper than what routine patching provides. Treat this as a wake-up call, not a one-off.