Critical “php2shell” flaw: our PHP updates are being rolled out

On Wednesday 21 October 2026 at 14:00 UTC, the PHP project released security versions fixing two critical remote code execution flaws: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 (CVSS v4.0). Researchers at watchTowr have nicknamed the pair “php2shell”.

Our teams are currently rolling out the fixed versions on the servers we manage. This article explains what these flaws are, why they are taken so seriously and what we are doing on our side.

Two flaws at the heart of PHP

These flaws do not affect WordPress, PrestaShop or any particular extension: they sit in the PHP engine itself, in the way it prepares and then cleans up each request. They can therefore be triggered whatever the site or CMS installed.

CVE-2026-109618: memory corruption after running out of memory

When a request exceeds its allowed memory, PHP aborts it. If that abort happens at the wrong moment, some of the request's internal data is only half initialised. The end-of-request cleanup nevertheless treats it as valid data, which corrupts memory and can lead to the execution of code chosen by the attacker.

According to the PHP project's advisory, the risk is highest with mod_php (PHP loaded directly into Apache): a demonstrated exploit lets an unauthenticated request trigger the attack before the site's code even runs.

CVE-2026-109619: stale global state being reused

The second flaw concerns per-request internal state that can outlive the memory that held it. The next request handled by the same PHP process (a PHP-FPM “worker”, for instance) may then reuse this stale state before it is reset. The temporary mitigations published by PHP show that it is linked to upload progress tracking (session.upload_progress) and, in PHP 8.5, to fatal error backtraces.

Why this is serious

• No authentication is required: a single HTTP request to a PHP site is enough, with no account or specific form.
• Every PHP site is affected: WordPress, PrestaShop, Joomla, Drupal, Laravel, Magento… Estimates range from 1.3 to more than 1.9 million servers exposed on the Internet.
• Details leaked before the release, which led the PHP project to announce the fix the day before. Exploit code is already circulating, unverified (and sometimes booby-trapped: do not run it).
• Early attacks have been mentioned by Cloudflare, not confirmed so far by CERT-FR or by CISA's catalogue of exploited vulnerabilities.
• The precedent speaks for itself: in 2024, CVE-2024-4577 was exploited less than 24 hours after its disclosure.

Affected and fixed versions

CERT-EU considers that every version since PHP 5 could be affected. Some vendors offer backported fixes for older branches, but the only lasting solution is to move to a maintained version.

What we are doing at HaiSoft

We had been following the announcement since the day before and were ready: the updates are being rolled out on our servers.

• Shared hosting: the fixed versions are being installed for every PHP version we offer. You have nothing to do, and the operation is transparent for your sites.
• Managed dedicated and virtual servers: we are updating PHP on each server; this work is included in your managed services contract. The fixed packages from the sury.org repository are already available and being installed.
• Servers running Plesk or Debian's official packages: Plesk and Debian have not yet released their fixed packages. We are following their releases and will apply the updates as soon as they come out.
• Sites still running PHP 8.1 or older: these versions will not receive a fix. We will contact the customers concerned to plan a migration to a maintained version.

Do you manage your own server?

1. Take stock of the PHP versions installed: php -v, Debian's php8.* packages, or plesk bin php_handler --list on Plesk.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution's fixed package), then restart every PHP-FPM service, and Apache if you use mod_php.
3. If the update has to wait, apply the PHP project's temporary mitigations, which reduce the risk without removing it.
4. Isolate applications running unmaintained versions (VPN, filtering, taking them offline), as CERT-EU recommends, until they are migrated.
5. Watch for any shell, curl or wget started by php-fpm, apache2 or httpd: it is the typical sign of a successful exploit.

The temporary mitigations recommended by the PHP project belong in php.ini or in the PHP-FPM pool configuration (not in a .user.ini file nor via ini_set()), followed by a restart of every worker:

; CVE-2026-109619
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0
; CVE-2026-109618: limit request size
; (8M without file uploads, 32M with)
post_max_size = 8M

For CVE-2026-109618, the PHP project also advises setting memory_limit = -1 without letting the application change it, and limiting request size at the web server or proxy level. This setting removes any per-script memory limit: keep it for cases where updating right away is truly impossible.