PHP2Shell: How We Closed and Verified Two Critical PHP Vulnerabilities

A vulnerability in PHP does not affect one application, but almost all of them: WordPress, Nextcloud, shops, forums, webmailers. We reacted accordingly fast. This post describes what we did and when, and what we checked ourselves along the way.

What the vulnerabilities are

Both bugs sit in the core of PHP and concern the time between two requests. A PHP-FPM process handles many requests one after another. Between them, it has to clean up its state completely.

• CVE-2026-109618 (RCE via OOM corruption): When PHP runs out of memory, it aborts the current request via a jump. In some places, this leaves memory in a half-finished state that the later cleanup still reads. According to the security advisory of the PHP project, this can be triggered deliberately and pushed all the way to code execution.
• CVE-2026-109619 (RCE via stale global state): Global pointers briefly point into the memory of a request. If they are not reset cleanly, the next request reads memory that has already been freed. Here too, the advisory of the PHP project describes code execution as the consequence.

Both are fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (PHP 8 changelog). The central fix is titled “Avoid state corruption via bailout”. The CVE entries: CVE-2026-109618 and CVE-2026-109619.

The timeline with times of day

On 20 October, the PHP project had announced that a security release for two critical vulnerabilities would be published the following day, scheduled for 16:00 German time. No details were available in advance. We used the time until then.

For most services, this meant an interruption of between half an hour and an hour. We accepted that deliberately: under our rule, no system goes back online without demonstrably patched PHP.

What we did

After the release, we updated all PHP installations under our responsibility: web hosting under Plesk and KeyHelp, the Nextcloud instances, the webmailers of the mail servers, our own website and internal applications. The older PHP versions 7.4, 8.0 and 8.1, which Plesk still ships, also received the corresponding updates.

An update alone was not enough for us. That is why three additional layers of protection apply:

1. session.upload_progress is off everywhere and locked. The publicly described attack chains use this feature to write data into the session. We switched it off server-wide and locked it with php_admin_flag so that neither a .user.ini nor a domain setting can switch it back on.
2. PHP processes are renewed regularly. With pm.max_requests = 500, every process terminates after 500 requests at the latest. State that lingers between requests therefore does not live indefinitely.
3. The web application firewall blocks the attack path. Our own ModSecurity rules reject requests that send the field PHP_SESSION_UPLOAD_PROGRESS, including in a variant with an obfuscated Content-Type.

On top of that, there is monitoring that checks every ten minutes for PHP crashes, for shells started by a web PHP process, and for configurations that switch upload_progress back on.

Why the Plesk panel was offline

The Plesk administration interface does not run on the PHP of the websites, but on its own, built-in PHP version. On our side, that was PHP 8.4.25 on 21 October, so unpatched, with upload_progress switched on and reachable from outside. This PHP cannot be replaced by ourselves.

We therefore switched the panel off until Plesk delivers an update. That came with Plesk 18.0.81.4 on the morning of 22 October. Before switching it back on, we checked that the panel actually runs on PHP 8.4.27, and we additionally switched off upload_progress there as well. The websites themselves ran normally during this time; only logging in to the panel was not possible.

What we checked ourselves

As early as the evening of 21 October, claims were circulating on social networks and on GitHub that the update does not help or that bypasses already exist. We did not rely on any of them, but checked each one ourselves.

• Running version instead of package list: An installed version says nothing about what a running process actually executes. We queried every PHP pool directly for the version it reports and whether upload_progress is off. In the process, we noticed, for example, that on one system the PHP of the websites was current but that of the command line was not.
• The fix itself: We compared whether the published versions actually contain the central fix. The affected source files are patched identically in all four release branches.
• Our own lab test: On a patched PHP 8.4.27 with upload_progress switched on, a file name chosen by the attacker ends up in the session file. With the feature switched off, no session file is created at all. Exactly this step is then missing from the known attack chains.

The unconfirmed claims

• “Remaining chains” after the patch: Several public repositories show alleged attacks against patched PHP. We read the code. Each of these chains presupposes at least one of the following: upload_progress switched on, a still unpatched version such as 8.4.26, or an additional vulnerability in the application itself, such as insecure unserialize(). Against our configuration, none of them works.
• A “follow-up” patch: A pull request in the PHP repository promised additional hardening against both vulnerabilities. It was closed the same evening and not merged. Another, older proposal on session handling is open, but plays no role when upload_progress is switched off.
• Exploit archives: In some cases, “working” exploits were offered for download, unencrypted and of dubious origin. With vulnerabilities of this size, such archives often contain malware themselves. We did not download them and did not run any foreign exploit code on our servers.

Traces of attacks

We searched access, error and firewall logs for the known patterns. What we found were scans. On 21 October at 16:22, for example, a scanner that identified itself as a PHP2Shell scanner sent a crafted request to our web hosting. The firewall blocked it, and the PHP behind it was already patched at that point. We found no indications of successful exploitation.

What is still open

The new versions 8.4.27 and 8.5.12 bring a bug of their own: in certain cases, the SimpleXML extension can crash (GH-24488). A correction is in progress. The crash has not occurred on our side so far. Our monitoring watches for it, and we will apply the follow-up versions as soon as they are released.

What this means for you

Web hosting, Nextcloud and mail: You don’t need to do anything. The updates and the hardening have been applied. One exception: if your application uses an upload progress bar via session.upload_progress, it now shows no progress. The upload itself still works.

Your own vServer or root server: Here you are responsible yourself. Check the running PHP-FPM service, not just php -v on the command line. At least 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is required. Then restart PHP-FPM and set session.upload_progress.enabled = Off. Anyone running Plesk or another panel with its own PHP additionally needs the panel vendor’s update.

We are happy to answer questions about your server through our ticket system.