PHP released a short advisory on October 23 warning of a separate, unlikely path that could let an attacker run code on a web server — just two days after emergency fixes for the critical PHP2Shell flaws. While the newly disclosed issue (CVE-2026-115560) is not being treated as an emergency, administrators should understand the configuration that creates the risk, confirm whether their apps are affected, and apply the recommended mitigation until a routine bugfix release fixes it.
What PHP announced
PHP described CVE-2026-115560 as a distinct problem from the two critical PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that were patched on October 21 in releases PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The new advisory explains the issue affects only a very specific runtime configuration and, because that setup is uncommon, the project will include the code fix in the next regular bugfix release rather than issuing another emergency patch. PHP has not listed which versions are affected, assigned a severity score, or said whether CVE-2026-115560 shares a root cause with the earlier PHP2Shell issues. No exploitation of CVE-2026-115560 has been reported.
How the narrow attack path works (technical summary)
According to PHP, exploitation via this path requires all of the following conditions to be true:
- The application sets session.serialize_handler to php_binary or php_serialize in its configuration.
- The application then changes that option to php at runtime (for example by calling ini_set()) before calling session_start().
- session.upload_progress (the feature that tracks file upload progress on uploads) is enabled.
If an application never switches the serialize handler while running, or if upload progress is disabled, this particular attack path is not available. PHP characterizes the setup as unlikely in practice.
Why PHP recommends disabling session upload progress
Because the narrow chain depends on session upload progress being enabled, PHP recommends turning off that feature as an immediate mitigation: set session.upload_progress.enabled=0. This is the same mitigation previously suggested for CVE-2026-109619; sites that already applied that setting after the October 21 advisory do not need to change anything further for this new issue. Session upload progress is enabled by default in many PHP installations, so administrators should explicitly verify the setting rather than assume it is off.
Who is at risk and what to check
- Likely not at risk: Most applications that never change session.serialize_handler at runtime.
- Potentially at risk: Applications that dynamically switch the session.serialize_handler from php_binary/php_serialize to php before session_start(), while leaving session.upload_progress enabled.
Immediate checks for administrators:
- Search your codebase for any use of ini_set(‘session.serialize_handler’, …) or other runtime changes to session.serialize_handler.
- Verify your php.ini (and any per-directory overrides) for session.upload_progress.enabled and set it to 0 if it is on and you cannot confirm your app is safe.
- Confirm you have applied the October 21 security updates (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35) that fixed CVE-2026-109618 and CVE-2026-109619.
Broader context: why action still matters
Even though CVE-2026-115560 is described as an unlikely configuration-dependent issue and has no public exploitation to date, the October 21 PHP2Shell disclosures saw rapid, widespread malicious activity against the earlier flaws. Amazon reported honeypot exploit attempts as early as October 17 (four days before disclosure), and Cloudflare observed traffic rising from tens of thousands of attempts within 45 minutes of the public fix to millions by the following day. Attackers attempted to weaponize those earlier vulnerabilities for Mirai-style botnets and widespread scanning; while many efforts so far have resulted in scanning and probing rather than confirmed remote code execution, the high volume of opportunistic attempts illustrates how quickly attackers swarm disclosed PHP flaws. That context makes rapid mitigations (like disabling upload progress) a sensible precaution even for low-likelihood paths.
Practical checklist for hosting providers and site operators
- If you haven’t already: apply the October 21 emergency updates for PHP (8.5.12, 8.4.27, 8.3.36, 8.2.35) to address the PHP2Shell CVEs.
- Immediately verify and, if needed, set session.upload_progress.enabled=0 across environments until PHP issues the routine bugfix release for CVE-2026-115560.
- Search for any runtime changes to session.serialize_handler and assess whether those code paths could run before session_start().
- Harden monitoring and logging around upload endpoints and session-related requests; watch for unusual POST traffic, file upload anomalies, and spikes in scanning activity.
- Apply standard hardening: keep backups, isolate application privileges, and ensure WAF and intrusion detection systems have up-to-date signatures to catch exploit attempts targeting related attack vectors.
Closing thoughts
CVE-2026-115560 appears to be a narrow, configuration-specific risk rather than a broadly exploitable emergency, but it arrived amid a larger wave of activity around PHP2Shell flaws. For most teams the right immediate action is simple and low-impact: confirm the October 21 patches are installed and disable session upload progress until the routine PHP release contains the official fix. That balance — timely mitigation without an emergency patch rollout — matches PHP’s assessment of likelihood while keeping exposure minimal.
Licensed under CC BY-ND 4.0 International
