CVE-2026-115560: third PHP2Shell bug gets no emergency fix; set upload_progress off

The PHP Security Team has reserved a third remote code execution CVE, CVE-2026-115560, in the same cluster of flaws as the two PHP2Shell bugs patched on 21 October, and it has decided not to ship an emergency fix. In an informational advisory published on php.net on 23 October, it says the bug is only reachable through an unlikely combination of configuration and application code, and that the full advisory and fix will come with the next regular PHP release. In the meantime it recommends one setting: session.upload_progress.enabled=0. If you already applied that setting for CVE-2026-109619, you are covered; if you have not, this is the second reason to do it.

Key points

• CVE-2026-115560 is a third RCE flaw tied to PHP's session upload progress feature; the PHP team says it will be fixed in the next regular bugfix release rather than in an emergency build.
• It is exploitable only if an application sets session.serialize_handler to php_binary or php_serialize, switches it to php at runtime with ini_set() before session_start(), and leaves session upload progress enabled.
• The mitigation is session.upload_progress.enabled=0; applications that never change the serialize handler at runtime can keep the feature on, according to the advisory.
• The first two bugs, CVE-2026-109618 and CVE-2026-109619 (both CVSS v4.0 9.2), are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026.
• PHP 8.1 and older no longer receive official updates; backport patches for 7.4, 8.0 and 8.1 are on GitHub.

What to do

Who is affected by CVE-2026-115560: only applications that match all three conditions in the PHP team's advisory. It says an application "must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start()", with session upload progress still enabled. We could not find affected version numbers, a severity score or the reporter in the sources we read; the advisory says the full details come with the next release.

What to do now:

1. Set session.upload_progress.enabled=0 in php.ini, the FPM pool or your server configuration, and restart every worker. The PHP team suggests this until the next regular bugfix release.
2. If you are still running a build older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35, update. Those releases fix the two critical bugs, and the same setting is part of the interim mitigation for one of them.
3. If you cannot update yet, the PHP team's interim mitigations for the first two bugs are: for CVE-2026-109618, memory_limit=-1, preferably through php_admin_value, plus post_max_size of 8M (no uploads) or 32M (uploads needed) with upload_max_filesize kept below it, and do not substitute RLIMIT_AS or RLIMIT_DATA; for CVE-2026-109619, session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0. The team calls these interim mitigations, not a complete fix. It also warns against relying on ini_set() or FPM .user.ini for the upload progress setting, so set it at the server level.
4. Check your code: search for ini_set('session.serialize_handler' and for session_start() calls that follow a change of handler. If you find none, the PHP team says the feature can stay on for this particular bug.

Compatibility check: disabling upload progress breaks features that read upload progress from the session, such as progress bars for large uploads that poll the server. Test that before you switch it off in production.

What happened

The PHP Foundation announced on 20 October that a critical security release would follow on Wednesday 21 October at 14:00 UTC, covering two vulnerabilities rated CVSS v4.0 9.2 each. It said it could release earlier if details became public or exploitation appeared in the wild. On 21 October it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The two bugs, which the press has called PHP2Shell, are:

• CVE-2026-109618: remote code execution through out-of-memory corruption. Out-of-memory handling can interrupt PHP while request data is only partly initialised.
• CVE-2026-109619: remote code execution through stale global state. Request-owned state can survive after its memory is freed and be used by a later request on the same worker.

PHP 8.6.0 RC4, which also carries the fixes, was released the same day and is not for production; RC5 is planned for 5 November.

On 23 October the PHP Security Team published the informational advisory for a third bug, CVE-2026-115560. The Register reported that the Foundation judged it to need a "very unlikely combination of configuration and specific PHP application code", which is why it will follow the regular release cycle. We could not confirm the exact release date of that fix; the advisory just says "the next regular bugfix release".

Meanwhile the situation around the first two bugs kept moving. According to TechCrunch, Amazon detected exploitation around 17 October, about a week before the patches were public, and Palo Alto Networks and Trail of Bits reported confirmed compromises and post-exploit activity late on 23 October. The Register, in an article on the same day, wrote that as of Friday no publicly confirmed successful compromises had been attributed to PHP2Shell. The two reports do not contradict each other so much as show how fast the picture changed over one day. We have covered the earlier exploitation in our report on PHP2Shell being exploited before its fix.

Background

According to TechCrunch, the two original bugs were first discovered in 2024 but were not considered exploitable at the time, and they were not patched. Earlier in 2026, researchers at Calif found a way to exploit them and alerted the PHP Foundation. Calif took part in the "Hack the Planet" initiative by OpenAI and Wiz, which verified its proof-of-concept exploits; The Register credits Wiz with finding the first two bugs, and TechCrunch credits Calif, so the two outlets emphasise different parties and we do not try to settle the question here. Calif told TechCrunch that AI helped with exploitation, but that most of the work relied on the researchers' own knowledge of PHP's code and exploitation history.

The Foundation gave major companies and web hosts early patch information under an embargo. TechCrunch reports that the Foundation blamed one company for pushing patches live hours before the embargo ended; the article does not quote the Foundation directly on that, so treat it as the outlet's summary.

Scale explains the attention. TechCrunch cites an estimate that around 70% of the web-facing internet relies on PHP, though its use has been declining, and says Cloudflare's chief executive, Matthew Prince, described an "exponential" number of exploit attempts after disclosure. Mandiant's Charles Carmakal, quoted by The Register, said some proof-of-concept exploits work against default mod_php deployments but not PHP-FPM.

How it works

Session upload progress is a PHP feature that lets a page report how far a file upload has got. While a file is uploading, PHP writes progress data into the user's session, and a second request reads it back. That means PHP is touching session data while it is still handling an upload.

The third bug sits in that area. The advisory's conditions say what an application has to do to be exposed: choose a non-default serialize handler in its configuration (php_binary or php_serialize; php is the default), switch it to php at runtime with ini_set() before session_start(), and leave upload progress on. The PHP team has not yet published the technical detail of why that combination is dangerous, so we do not describe the mechanism further. The PHP team also advises setting the upload progress option at the server level and not through ini_set() or .user.ini for the earlier bug, CVE-2026-109619, where the same setting is part of the mitigation.

What it means

For administrators: the practical outcome is unchanged: update to the fixed builds, and set session.upload_progress.enabled=0 as a standing mitigation until the next release. There is no reason to wait for the third bug's fix to turn the feature off.

For application developers: the PHP team says an application that never changes the serialize handler at runtime can keep upload progress on. That makes the code search above the quickest way to decide how urgent this is. Frameworks and plugins that call ini_set() on the handler deserve the most attention.

For teams on old PHP: the PHP team notes that 8.1 and older no longer receive official updates and that backports for 7.4, 8.0 and 8.1 are on GitHub. Running an unsupported branch means relying on those unofficial patches. PHP 8.2 reaches end of life on 31 December 2026, according to the Foundation's own table.

For the industry: a project that ships emergency fixes for two bugs and defers a third on a risk judgement is making a call that is easy to second-guess. The PHP team's reasoning is that the exploit conditions are narrow. The risk is that once an advisory exists, attackers read it, and the description of the exact conditions is now public.

What we don't know yet

• The fix version and date for CVE-2026-115560. The advisory only says the next regular bugfix release.
• The severity score and the affected versions. We found neither.
• Who reported it. The sources we read do not say.
• Whether it is being exploited. We found no report of exploitation of this third bug. For the first two, reports differ by hour, as above.
• The scope of confirmed compromises from the first two bugs. Palo Alto Networks and Trail of Bits are reported to have confirmed some; we have not read their reports and cannot size them.

What to watch next

Watch php.net for the next regular bugfix release and the full advisory for CVE-2026-115560, the planned PHP 8.6.0 RC5 on 5 November, and threat reports from the companies that confirmed compromises. If a public proof of concept for the third bug appears, the narrow conditions will decide how far it spreads. Until then, the checklist above takes minutes.

Sources

• PHP.net announcements: critical release notices of 20 and 21 October and the 23 October informational advisory (primary source)
• The Register: There's a third PHP2Shell bug, but it won't get an emergency fix
• TechCrunch: PHP-ocalypse, how two critical web bugs almost broke the internet