PHP: third RCE CVE-2026-115560 unpatched, PHP2Shell attempts

On October 23, 2026, two days after the emergency patches for PHP2Shell, the PHP security team published an informational advisory on a third remote code execution vulnerability, CVE-2026-115560. There is no fixed version yet: it will come with the next regular release. In the meantime a configuration mitigation is available, the same one already recommended on October 21 for one of the two PHP2Shell flaws.

Our October 20 article covered the announcement of the two critical vulnerabilities CVE-2026-109618 and CVE-2026-109619. What follows is new: the third CVE, the fixed versions released on October 21 and the state of the attacks.

CVE-2026-115560: the conditions

According to the PHP advisory, as reported by BleepingComputer, The Register and Security Affairs, and to the advisory of the Korean KrCERT/CC, the flaw lies in session handling and can only be exploited when all of these conditions are met:

1. session.serialize_handler is set to php_binary or php_serialize in the configuration;
2. the application switches it back to php at runtime with ini_set(), before calling session_start();
3. session.upload_progress.enabled is on, as it is by default.

The PHP project considers this combination unlikely in real-world use and is therefore handling it in the regular release cycle, with a full advisory in the next release. Applications that never change the serialize handler at runtime are not exposed through this path, even with upload progress enabled.

As of today, according to Security Affairs, PHP has not named the affected versions, the date of the fix or a severity score, and has not explained whether the flaw shares a root cause with CVE-2026-109619. The October 21 releases do not fix it. None of the sources reports attacks against this CVE.

PHP2Shell: patches, exploitation attempts and end-of-life versions

The two flaws announced on October 20, now known as PHP2Shell, are memory-safety bugs in the PHP engine (The Register), with a CVSS v4.0 score of 9.2 and unauthenticated code execution. According to Security Affairs the faulty code dates back to PHP 5.4, released in 2012. The fixes shipped on October 21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

On exploitation, the sources agree on one point: as of October 23 no successful compromise has been publicly confirmed. Attempts, however, are numerous:

• Amazon saw the first attempts on October 17, before the patches, with different payloads and infrastructure pointing to multiple actors (SecurityWeek, BleepingComputer, The Record);
• Cloudflare, according to Security Affairs, counted tens of thousands of attempts in the 45 minutes after disclosure and millions by October 22;
• Sophos, Arctic Wolf, Hunt.io and Cobalt link some of the attempts to Mirai-style botnets (Potassium) that try to install malware for DDoS attacks; Sophos retracted an earlier report of successful exploitation.

The sources disagree on feasibility. According to Sansec, quoted by SecurityWeek, public exploits fail against installations with default settings; Mandiant, quoted by The Register, says instead that it validated some PoCs capable of RCE against default mod_php deployments, but not PHP-FPM. VulnCheck says it has an exploit for CVE-2026-109618 that bypasses ASLR on x86-64 with error display turned off, the recommended production setup; it is reserved for its customers. SOCRadar found an exploit chain for PHP 8.4.26 on Apache mod_php on an attacker server, tried on about twenty websites without success.

The MITRE ATT&CK technique is T1190 (Exploit Public-Facing Application). The sources report no public indicators of compromise.

Patching is slow. According to Censys data reported by The Record, on October 22 more than 41 million internet-facing PHP services ran affected versions and about 1 million a fixed one. Qualys, based on anonymized customer data, estimates that 71% of instances run the end-of-life 5.4 to 8.1 branches, most of which will never get a patch from the project.

Impact in Europe and Italy

According to SecurityWeek, on October 21 several government, school and hospital websites in Europe were taken offline as a precaution while updates were applied, and in the UK 32 government services were unavailable. Romania’s DNSC also issued an alert on the two vulnerabilities.

For NIS2 entities, what we wrote on October 20 still applies: document the inventory, priorities and update times, and assess notification to the national CSIRT (CSIRT Italia in Italy) in case of a significant incident. In healthcare, PHP-based patient portals should be checked first, including those run by external suppliers.

What to do now

1. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the fixed versions from your distribution or hosting provider, and check the version actually used by the web server (PHP-FPM or module), not just the one from php -v.
2. Set session.upload_progress.enabled=0 in php.ini and in the PHP-FPM pools, then restart all PHP workers, as KrCERT/CC advises. If you already applied it for CVE-2026-109619, keep it: according to PHP nothing else is needed.
3. Review the code: look for ini_set() calls on session.serialize_handler in your applications and third-party components.
4. End-of-life versions: ask your distribution or hosting provider whether fixes are available; otherwise plan the migration and limit public exposure in the meantime.
5. Prioritize mod_php: Apache mod_php installations are where the PoCs validated by Mandiant and the chain found by SOCRadar are focused.
6. Monitor web server logs for anomalous requests and PHP hosts for unexpected processes or outbound connections.

How ARXDOME helps

ARX Shield shows, for each machine, the packages with open vulnerabilities, highlighting those already exploited; the ARX Sentry inventory lists software and processes on servers with the agent, which helps find PHP and PHP-FPM. ARX Expose shows which of your company’s public services expose recognized products, so you can start with those reachable from the internet.

Last updated: 24 October 2026