The PHP project has disclosed a new remote-code-execution risk, CVE-2026-115560, and is urging administrators to disable session upload progress until the vulnerability is addressed in a regular bugfix release. PHP characterizes the issue as an unlikely attack vector because exploitation requires an unusual combination of server configuration and application behavior.
The flaw affects applications that configure session.serialize_handler as php_binary or php_serialize, then switch the handler to php at runtime with ini_set() before calling session_start(). Session upload progress must also remain enabled. Under those conditions, an unauthenticated attacker may be able to abuse session processing to reach remote code execution.
PHP published the informational advisory on October 23, two days after releasing PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to address separate critical vulnerabilities. Those releases do not constitute a fix for CVE-2026-115560; PHP said the new issue will receive a full advisory with the next regular release. PHP 8.1 and older are no longer supported by the project, although some operating-system and long-term-support vendors may provide backported fixes.
The project recommends setting session.upload_progress.enabled=0 and restarting every PHP worker. The setting should be applied in php.ini, an FPM pool or another server-level configuration that takes effect before request parsing; PHP cautions that relying on ini_set() or a per-directory .user.ini setting may not block the relevant processing path. Applications that never change the session serializer at runtime can leave upload progress enabled, according to the advisory.
No CVSS score for CVE-2026-115560 was available from the National Vulnerability Database in the available reporting, and PHP has not reported exploitation in the wild or attributed the activity to a threat actor. Public proof-of-concept code has nevertheless appeared on GitHub, including a researcher’s claim of successful execution against PHP 8.4.27 with the vulnerable configuration. Those repositories are not vendor validation, but their publication increases the importance of auditing applications for runtime serializer changes rather than assuming that the recent PHP2Shell updates close this separate issue.
