CVE-2026-115560: New Unpatched PHP RCE Risk Requires Immediate Mitigation

PHP has disclosed CVE-2026-115560, a new remote code execution risk affecting web applications that use an unusual combination of PHP session configuration and runtime behavior. The issue was disclosed on October 23, 2026, only two days after PHP released emergency fixes for the critical PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619.

Unlike those earlier vulnerabilities, CVE-2026-115560 has not triggered another emergency PHP release. The PHP security team considers the vulnerable configuration unlikely in typical deployments and plans to address the flaw through its next regular bugfix cycle. Until then, administrators are advised to disable PHP’s session upload progress feature where the vulnerable configuration may exist.

The new vulnerability is also important because installing PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35—the releases that fixed the two earlier PHP2Shell flaws—does not remediate CVE-2026-115560. Fully updated systems may therefore remain exposed if their applications meet the specific configuration prerequisites.

Security teams seeking CVE-2026-115560 detection opportunities should prioritize visibility into PHP session handling, unusual multipart uploads, unexpected changes to session serialization behavior, and suspicious child processes spawned by PHP or web-server workers.

SOC Prime’s AI-Native Detection Intelligence Platform enables security teams to strengthen coverage for emerging vulnerability exploitation and related post-compromise behavior across SIEM, EDR, and Data Lake environments.

Click Explore Detections to access relevant detection content and hunting logic. To Detect CVE-2026-115560, defenders should combine PHP configuration assessment with web, endpoint, application, and reverse-proxy telemetry while a vendor patch remains unavailable.

Security practitioners can also leverage Prime Architect to transform newly disclosed vulnerability intelligence into Sigma rules and hunting queries, validate detection logic, and translate relevant detections across supported security platforms.

Contact Sales

CVE-2026-115560 analysis

PHP published an informational advisory on October 23 describing a potentially exploitable interaction between session serialization and the session upload progress feature.

According to the PHP security team, an application must satisfy several specific conditions before the issue can occur:

• session.serialize_handler must initially be configured as php_binary or php_serialize.
• Application code must subsequently change the handler to php at runtime using ini_set().
• That change must occur before session_start() is called.
• session.upload_progress.enabled must remain enabled.

Applications that never switch the serialization handler at runtime are not exposed through this specific path and can continue using session upload progress. PHP describes the vulnerable combination as uncommon.

This distinction substantially narrows the attack surface compared with CVE-2026-109618 and CVE-2026-109619. The earlier PHP2Shell vulnerabilities affected web-serving PHP installations broadly and required emergency updates. CVE-2026-115560 instead depends on application-specific configuration and code behavior.

The details for CVE-2026-115560 remain intentionally limited. PHP has not yet published the complete technical root cause, exact vulnerable version ranges, a CVSS score, or the specific internal memory or session state transition that ultimately produces the RCE condition. The vendor says those details will be included with the next regular release.

Based on the disclosed prerequisites, the vulnerability appears connected to inconsistent handling of session data when an application changes serialization formats during request processing while PHP’s upload-progress mechanism is active. However, the exact exploitation primitive should not be inferred beyond what PHP has formally disclosed.

CVE-2026-115560 affects applications meeting the vulnerable configuration pattern, including applications running fully patched PHP releases containing the October 21 PHP2Shell fixes. PHP has not yet stated which PHP branches or historical releases contain the underlying flaw.

This means administrators should not determine exposure solely from the installed PHP version. Instead, they need to assess application and server configuration.

A useful first step is checking whether session upload progress is enabled:

session.upload_progress.enabled=1

Administrators should also identify any application code calling ini_set() to modify session.serialize_handler, particularly transitions from php_binary or php_serialize to php.

The new flaw is separate from CVE-2026-109619 even though the mitigation overlaps. Disabling session upload progress was already recommended as a risk-reduction measure for one of the original PHP2Shell vulnerabilities. Organizations that kept that setting disabled after the October 21 emergency update are already protected against the newly disclosed path, according to PHP.

There is currently no public CVE-2026-115560 PoC documented by PHP or the two supplied reports. The security team has also not disclosed enough technical information to reproduce the vulnerability reliably from the public advisory alone.

This is notably different from the earlier PHP2Shell flaws, for which various proof-of-concept attempts and exploit activity emerged around disclosure. Those attacks should not be attributed to the new vulnerability.

No exploitation of CVE-2026-115560 has been reported as of October 26, 2026. The Hacker News specifically distinguishes ongoing PHP2Shell scanning and exploitation attempts from this newer vulnerability, noting that the observed activity targets CVE-2026-109618 and CVE-2026-109619.

As a result, CVE-2026-115560 IOCs such as malicious IP addresses, domains, hashes, payloads, or confirmed exploit request patterns are not currently available.

Until more technical details emerge, defenders should focus on behavioral and configuration-based indicators, including:

• PHP applications changing session.serialize_handler during execution
• Session upload progress remaining enabled on applications with custom session logic
• Unexpected multipart POST traffic to applications handling PHP sessions
• PHP-FPM, php-cgi, Apache, or other PHP-serving processes spawning shells or scripting interpreters
• Unexpected outbound network connections from PHP workers
• Newly created files inside web roots or writable application directories
• Unusual changes to session files or session storage
• Web shells, scheduled jobs, or unauthorized persistence created by PHP service accounts

Application developers should also review custom session-handling logic. Framework extensions, legacy applications, internal platforms, or custom authentication systems are more likely than straightforward PHP deployments to modify serialization settings dynamically.

The disclosure comes during an already active period of PHP exploitation activity. The original PHP2Shell vulnerabilities were patched on October 21, and multiple security companies subsequently observed widespread probing and exploit attempts. However, PHP and security researchers have not linked those campaigns to CVE-2026-115560.

CVE-2026-115560 mitigation

PHP currently recommends one direct defensive measure:

session.upload_progress.enabled=0

Administrators should apply the setting through php.ini, PHP-FPM pool configuration, Apache configuration, or another server-level mechanism that takes effect before request processing.

Organizations that disabled the feature while mitigating CVE-2026-109619 and have left it disabled do not need an additional configuration change for this vulnerability.

After changing the setting, restart PHP workers and relevant web services to ensure existing processes load the updated configuration. Depending on the environment, this may include restarting PHP-FPM pools, Apache workers, containers, or other PHP application runtime processes.

Administrators can verify the effective setting through PHP configuration inspection rather than assuming a central php.ini value applies everywhere. PHP deployments frequently combine settings from:

• Global php.ini
• conf.d files
• PHP-FPM pool configuration
• Apache directives
• Container-specific configuration
• Application-level .user.ini
• Runtime calls to ini_set()

The most important exposure assessment is application-specific. Search application source code for runtime modification of the session serializer, particularly patterns involving:

ini_set(‘session.serialize_handler’, ‘php’)

Applications that never change the serializer from php_binary or php_serialize to php before session_start() do not match the vulnerable scenario PHP has disclosed.

Organizations should nevertheless maintain the October 21 PHP2Shell security updates. Disabling upload progress addresses the newly identified path but does not replace the emergency fixes for CVE-2026-109618 and CVE-2026-109619.

Supported installations should therefore remain on at least:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Those releases remediate the earlier PHP2Shell issues but not the newly disclosed vulnerability.

Security teams should also inventory unsupported PHP installations. PHP 8.1 and earlier releases no longer receive routine upstream security updates, meaning organizations operating legacy environments may have difficulty determining complete exposure once the final CVE advisory is published.

If disabling session upload progress is operationally impossible, organizations should first determine whether their applications actually modify the serialization handler dynamically. PHP explicitly states that applications that never perform this runtime switch can leave session upload progress enabled.

As additional safeguards, defenders can:

• Limit external access to sensitive PHP applications.
• Apply restrictive reverse-proxy rules around unnecessary file-upload endpoints.
• Monitor multipart requests associated with PHP sessions.
• Alert on anomalous PHP worker child processes.
• Apply least privilege to PHP-FPM and web-server accounts.
• Prevent PHP services from writing to executable directories where possible.
• Restrict outbound connectivity from web application workloads.
• Monitor web roots and temporary directories for unauthorized file creation.

AWS has also noted that its PHP application WAF rules can block POST requests combining PHP session identifiers with the PHP_SESSION_UPLOAD_PROGRESS field, providing another defensive layer for environments that cannot immediately make configuration changes. This type of filtering should still be considered defense in depth rather than a replacement for PHP’s recommended configuration change.

Once PHP releases the regular bugfix update containing the permanent fix, organizations should deploy it promptly even if the temporary mitigation is already enabled.

After patching, administrators can decide whether session upload progress needs to be re-enabled based on application requirements.

If exploitation is suspected, isolate the affected application server and preserve web, PHP, reverse-proxy, endpoint, and network telemetry. Review writable directories for web shells or newly created files, inspect PHP child processes, and identify credentials or secrets accessible to the compromised service.

Because successful exploitation could potentially result in code execution with the privileges of the PHP worker, responders should rotate relevant application credentials, database secrets, API tokens, cloud keys, and other sensitive information if compromise cannot be excluded.

Disclaimer: Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.