PHP “PHP2Shell” vulnerability CVE-2026-109618 and CVE-2026-109619: versions to install and checks

The short answer: two flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell”, let a remote, unauthenticated attacker run code on a web server. The PHP project fixed them on 21 October 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA added them to its catalogue of exploited vulnerabilities on 26 October. Any business running a website, online shop, ERP or API on PHP should update, restart the PHP processes and check the version actually in service.

In Morocco, PHP is everywhere: WordPress sites, online shops, Dolibarr ERP, intranets and custom business tools, often run by a hosting provider or a web agency. The DGSSI’s maCERT has published several bulletins on this since 21 October and asks organisations to extend checks to their providers. This alert brings together what the official sources say and the checks to carry out.

What is affected

Both flaws sit in PHP’s internal request handling, not in any particular application:

• CVE-2026-109618: on an out-of-memory error, PHP aborts the request while some data is not yet initialised; the cleanup procedure reads it anyway. Several ways of triggering this lead to remote code execution.
• CVE-2026-109619: some PHP global state can keep pointing at the memory of a request that has already been freed, and be read again by a later request handled by the same process. Remote code execution is possible here too.

According to the PHP advisory, all web deployments are exposed: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The advisory states that full exploitation was validated on Apache mod_php, and considers PHP-FPM, FrankenPHP and LiteSpeed vulnerable or likely vulnerable.

Product	Affected versions	Fixed version
PHP 8.5	earlier than 8.5.12	8.5.12
PHP 8.4	earlier than 8.4.27	8.4.27
PHP 8.3	earlier than 8.3.36	8.3.36
PHP 8.2	earlier than 8.2.35	8.2.35 (end of life on 31 December 2026)
PHP 8.1, 8.0, 7.4	all	no official release: minimal patches to build, distribution packages or migration
PHP for Windows	builds before the fixed ones	8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1 (published 26 October, with Brotli 1.2.1)

Sources: php.net security announcements of 21 and 26 October 2026, advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

Severity and exploitation

• Published severity: the PHP project rates both flaws CVSS v4.0 9.2, critical, as shown on the NVD. maCERT rates the risk and impact as critical (bulletin 69782110/26).
• Exploitation: CISA added both CVEs to its KEV catalogue on 26 October 2026, as “PHP Memory Corruption Vulnerability” and “PHP Stale Internal Request-State Vulnerability”. maCERT reports that exploit code is publicly available.
• Third-party products: several appliances and software products embed PHP. maCERT has published dedicated bulletins for Citrix, Cisco, F5, QNAP and Tenable products affected by PHP2Shell. For these devices, wait for and apply the equipment vendor’s update rather than patching PHP by hand.

Interim mitigations, if the update has to wait a few hours

The PHP advisory describes them as partial: they reduce the risk, they do not remove it.

1. Against CVE-2026-109619: set session.upload_progress.enabled = 0 in php.ini, in the PHP-FPM pool or in the server configuration, then restart every process. Setting it through ini_set() or .user.ini does not count. On PHP 8.5, also set fatal_error_backtraces = 0.
2. Against CVE-2026-109618: the advisory suggests enforcing memory_limit = -1 at administrator level, checking that no pool or application sets a finite limit again, and keeping a conservative post_max_size. It explicitly advises against RLIMIT_AS and RLIMIT_DATA, which trigger the vulnerable path.
3. In front of the server: at the reverse proxy or web application firewall, limit request size and the number of fields, multipart parts and headers. If the application has no file-upload forms, block multipart requests.

On 22 October maCERT published a specific bulletin on a common trap: believing remediation is done while the server still runs the old engine.

Checks to carry out

• Inventory everything that runs PHP: public sites, forgotten staging sites, ERP, APIs, intranets, hosting panels, including what your providers and hosting company manage.
• Check the running version, not the package version: php -v shows the command-line tool, which can differ from PHP-FPM or Apache. Check the version of each PHP service and its start time, which must be later than the update.
• Actually restart: PHP-FPM, Apache with mod_php, CGI services. For Docker, recreate the containers from the fixed image; pulling the new image is not enough.
• Check where the fix comes from: for PHP 8.1 and earlier, a package from the distribution or a support vendor, never an unofficial patch found online.
• Look for traces: new PHP files in web directories, recently created admin accounts, unknown scheduled tasks, unusual outbound connections from the server. CISA also requires US federal agencies to carry out forensic triage on top of patching.
• Check third-party equipment: apply updates published by Citrix, Cisco, F5, QNAP or Tenable for the products listed by maCERT.

Our view for businesses in Morocco

The riskiest case we see is the server nobody feels responsible for: the website an agency rebuilt a few years ago, the old Dolibarr server left online after a migration, the staging site exposed on the internet. The second is shared hosting: you cannot update PHP yourself, but you can and should ask your host for its version and the date it was applied. If you use Dolibarr, our guide to Dolibarr in Morocco: hosting and setup explains how to isolate and maintain the server.

A flaw like this also points back to three basics: an immutable 3-2-1 backup so a compromised server can be rebuilt, managed EDR and 24/7 monitoring to spot abnormal behaviour, and a planned patching method such as the one we describe for FortiOS upgrades. For organisations in scope, law 05-20 and DGSSI requirements also require these alerts to be handled.

How we can help

We inventory your PHP servers and applications, including those run by third parties, apply the fixed versions with a controlled restart, check for signs of compromise and set up 24/7 monitoring, with critical incidents handled in under 15 minutes. See our approach to business cybersecurity in Morocco, then request your free initial audit: we reply within 24 business hours.

Sources: PHP security announcements, advisory GHSA-w8hw-w9fx-j79w, CISA KEV catalogue, NVD CVE-2026-109618, NVD CVE-2026-109619, maCERT bulletins (DGSSI).