PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches

CVE-2026-115560 is a separate PHP vulnerability that could provide a path to code execution on a web server. PHP considers it an unlikely risk because only a narrow application setup is exposed. The project published an informational advisory on October 23 rather than issuing an emergency patch.

The setup requires an application to configure session.serialize_handler as php_binary or php_serialize, change it to php with ini_set(), and make that change before session_start(). Session upload progress must also remain enabled. Applications that never change the handler at runtime are not exposed through this path.

This differs from CVE-2026-109618 and CVE-2026-109619, the critical PHP2Shell flaws patched two days earlier. Those flaws allowed unauthenticated attackers to run code and prompted emergency releases for PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Those releases do not fix the new issue.

A remote code execution, or RCE, vulnerability allows someone to make a computer run code over a network. The attacker does not need to sit at the server or use its normal administration interface. In the PHP incidents, the earlier flaws let an attacker without an account run code on a web server.

Once code runs, the attacker may be able to perform actions available to the vulnerable web process. Depending on permissions and the flaw’s limits, that could include reading data, changing files, installing software, or using the server for further attacks. RCE does not automatically mean total control, but it is among the most serious software weaknesses.

The article reports that attackers tried to install a Mirai botnet variant through the earlier PHP2Shell flaws. Sophos and Arctic Wolf linked those attempts to the botnet, although Previdian, Wordfence, and others found scanning and probing without confirmed code execution. No exploitation has been reported for CVE-2026-115560.

The number of exposed applications cannot be calculated from the article. PHP does not provide a count, percentage, or inventory of affected deployments. It describes the vulnerable setup as narrow and says the combination is unlikely in practice.

An exposed application must first set session.serialize_handler to php_binary or php_serialize. It must then change that option to php by calling ini_set(), and do so before session_start(). Session upload progress must also still be enabled. Missing any required condition removes this described exposure path.

That makes the likely population much smaller than the total number of PHP applications. Applications that leave the serialize handler unchanged at runtime can keep session upload progress enabled without being exposed through this path. The safest accurate answer is therefore “unknown, but likely very few,” rather than a precise figure. PHP has not published affected versions or a severity score.

When session upload progress is disabled, an application no longer gets PHP’s built-in tracking of a file upload’s progress. The article does not describe this as disabling file uploads themselves. It identifies the setting as the feature that must remain enabled for CVE-2026-115560’s described path to occur.

PHP recommends setting session.upload_progress.enabled=0. The mitigation is simple and applies before the routine bugfix release arrives. It avoids the risky feature rather than changing the application’s session serialization behavior. The same setting was already listed as a mitigation for CVE-2026-109619.

This advice is especially useful because session upload progress is enabled by default. Administrators who applied the setting after the October 21 PHP2Shell advisory and left it in place need to do nothing more for the new issue. PHP plans to provide the full advisory and permanent fix in its next regular release cycle.

Current attack activity is focused on CVE-2026-109618 and CVE-2026-109619, the two PHP2Shell flaws patched on October 21. The article explicitly says CVE-2026-115560 has not been reported under attack. That distinction matters because the new issue is separate and remains in the routine-release process.

Amazon said its honeypots recorded an exploit attempt against the two earlier flaws on October 17, four days before disclosure. Cloudflare then saw attempts rise from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22. Attackers also tried to install a Mirai botnet variant.

Those attempts have so far failed to produce confirmed code execution, according to Previdian, Wordfence, and others. Researchers say a reliable exploit is harder to build than expected. The reported scanning and probing therefore concern the older flaws, not CVE-2026-115560.

PHP’s different response reflects the apparent reach and urgency of each problem. CVE-2026-115560 requires an unusual combination of session settings, a runtime configuration change, and enabled upload progress. PHP therefore considers exploitation through this path unlikely and is not issuing an emergency fix.

The project instead recommends disabling session upload progress until the next routine bugfix release. It plans to publish a full advisory for CVE-2026-115560 with that release. PHP has not yet stated which versions are affected or which releases will contain the permanent fix.

The two PHP2Shell flaws presented a more immediate danger. They allowed attackers without accounts to run code on a server, and attacks appeared before and soon after public disclosure. PHP issued emergency updates on October 21: versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Those updates do not fix the new vulnerability.

PHP sessions store application state between requests, and PHP uses a session.serialize_handler setting to determine how that state is represented. File-upload handling can also use sessions to track upload progress. The article identifies an unsafe interaction between these features, rather than describing a normal session or upload as dangerous.

The required sequence is specific. An application sets the handler to php_binary or php_serialize in configuration. Before calling session_start(), it changes the handler to php with ini_set(). Session upload progress must still be enabled. If the application never changes the handler while running, this described path does not apply.

The article does not explain exactly how that interaction becomes code execution, so the internal mechanism should not be inferred. It does establish the practical defense: set session.upload_progress.enabled=0. PHP says this removes a required condition until a routine release supplies the fix. The feature is enabled by default.