Critical PHP vulnerabilities of October 2026: risks, affected versions and patch plan

1. What PHP confirmed on 21 October

The security advisory published on 21 October with the fixes removes the previous day’s uncertainties. PHP confirms two critical vulnerabilities allowing unauthenticated remote code execution: CVE-2026-109618, where an interruption on exceeding the memory limit leaves internal request data only partially initialised, which request cleanup then treats as valid, and CVE-2026-109619, where request-owned internal state survives the release of its memory and may be used by a later request handled by the same worker. Every installation serving web requests is affected (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed); PHP considers the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs.

On the evening of 20 October CERT-EU had published advisory 2026-018, which repeated the identifiers quoted by researchers and recommended preparing for immediate patching, or isolating internet-facing applications if the fix could not be applied quickly. The Drupal security team did the same on 21 October. Cloudflare, part of the coordinated mitigation effort with the PHP Foundation, OpenAI and Wiz, says it observed attack traffic targeting its customers while the vulnerability had leaked before the official release date, and saw attackers mutating their payloads to try to bypass its rules.

• Confirmed by PHP: two critical flaws, CVSS 4.0 score of 9.2, unauthenticated remote code execution, identifiers CVE-2026-109618 and CVE-2026-109619, fixes published on 21 October 2026 at 14:00 UTC in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Also confirmed by PHP: there are no complete mitigations, updating is the only safe choice. A few settings reduce exposure to specific attack paths without making the installation safe (see section 6).
• Refuted: a score of 10, an announcement on 22 October, a fix through a simple php.ini setting. Cloudflare for its part recalls that the flaws are in the PHP runtime itself: updating the site’s code or plugins fixes nothing, PHP itself must be updated or the hosting provider asked to do so.

2. Why remote code execution changes everything

A remote code execution vulnerability lets an attacker run their own commands on the server from a single HTTP request, with no account or password if the flaw is reachable before any authentication. The attacker then holds the rights of the user running PHP: reading the configuration and database credentials, dropping a control script (webshell), altering the pages served to visitors.

For an online store this means exfiltrated customer data, card-skimming scripts injected into the checkout and a database that can be modified. For a business application connected to an ERP or a CRM, it is a gateway into the information system. The compromised server also serves as a relay to encrypt data (ransomware) or mine cryptocurrency.

Precedents set the pace. The PHP-CGI flaw CVE-2024-4577, fixed on 6 June 2024, was exploited within 24 hours according to Akamai, and the TellYouThePass ransomware used it from 8 June according to Imperva. For the October 2026 flaws, Sansec, a Magento security specialist, expected mass attacks within minutes of the fixes being released, and Cloudflare confirms it observed attack traffic targeting its customers even before the official disclosure.

3. Which PHP versions are fixed

PHP only fixes the branches it still supports. The versions released on 21 October 2026 are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP recalls that the 8.2 branch reaches end of life on 31 December 2026 and will receive no further security fixes after that date. PHP 8.1 reached end of life on 31 December 2025; PHP 8.0, 7.x and 5.x have received nothing for a long time. Given the severity of the flaws, the security team has nevertheless published minimal source backports for PHP 7.4, 8.0 and 8.1, for those who build PHP themselves or have no LTS vendor; Linux distributions and LTS vendors received the patches in advance, and some provide backported packages for those older branches.

The installed base is considerable. According to W3Techs, PHP powers about 69% of websites whose server-side language is known, and nearly one PHP site in two still runs an end-of-life branch (PHP 5, 7, 8.0 or 8.1). On the WordPress side, wordpress.org statistics show that about one site in three runs a PHP version that will not be fixed.

• PHP 8.5 and 8.4: update to 8.5.12 or 8.4.27, branches in active support.
• PHP 8.3: update to 8.3.36, security support until 31 December 2027.
• PHP 8.2: update to 8.2.35, but support ends on 31 December 2026: plan the migration to 8.3 or 8.4 now.
• PHP 8.1 and earlier: no official release. Minimal source backports provided by PHP for 7.4, 8.0 and 8.1, backported packages from some distributions and hosts, otherwise migration and isolation.

4. Magento, PrestaShop, WordPress, Symfony, Laravel…: where your application stands

The PHP version you can install depends on the version of your application. That is where the deadlock appears: an old platform requires a PHP version that is no longer fixed, and updating PHP without updating the application breaks the site. The official compatibility matrices, as of 21 October 2026, give the following room for manoeuvre. The same questions arise for any other PHP application, internal tool, API, ERP connector or custom site: the minimum version is set by the framework and libraries in use.

Two situations call for a quick decision. Magento 2.4.4 and 2.4.5, limited to PHP 8.1, as well as PrestaShop 8, whose recommended version is PHP 8.1, have no fix path without upgrading the application. WordPress sites still on PHP 7.4, common on shared hosting, are in the same position.

• Magento and Adobe Commerce: 2.4.6 accepts PHP 8.1 or 8.2; 2.4.7 PHP 8.2 or 8.3; 2.4.8 PHP 8.3 or 8.4; 2.4.9 PHP 8.5. Below 2.4.6, PHP 8.1 at best.
• WordPress 6.x: PHP 8.3 recommended, works from 7.4 to 8.5; check plugins and theme before changing branch.
• PrestaShop: version 8 is officially capped at PHP 8.1; PrestaShop 9.0 accepts PHP 8.1 to 8.4 and 9.1 up to 8.5.
• Symfony: 6.4 LTS requires PHP 8.1 minimum, 7.4 LTS PHP 8.2, 8.x PHP 8.4. Laravel 12 and 13 run on PHP 8.2 to 8.5; Laravel 11 has been unmaintained since March 2026.
• Drupal: 10.4 to 10.6 accept PHP 8.1 to 8.4, Drupal 11 needs PHP 8.3 minimum. Dolibarr 23: PHP 7.2 to 8.4.

5. The five-step action plan

Order matters: inventory before patching, patch before monitoring, but without waiting for the end of the inventory to fix what is already identified. Count in hours, not days, starting with internet-facing servers.

Beware of false certainties when verifying: the php -v command on the command line may show a different version from the one used by the web server (PHP-FPM, Apache module, per-directory version selector at some hosts). Check the version actually served, then restart PHP-FPM or the web server after the update so that it takes effect.

• Inventory: list every server, container and shared hosting account that runs PHP, with the version served and the application installed. Do not forget staging environments, old sites left online and internal tools.
• Update: install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (your distribution's repositories, Sury repositories for Debian and Ubuntu, official Docker images, official sources). PHP warns that the volunteer-maintained Remi repository will not have the updates on the day and recommends switching to distribution packages or building from source. Rebuild container images without relying on a tag already present in the cache.
• Verify: check the version after restart, on every server and every directory, then test the critical journeys (login, cart, payment, ERP exports).
• Isolate what cannot be fixed: restrict access by IP address or VPN, place a web application firewall (WAF) in front of the site (Cloudflare enables its rules by default on every plan, see section 6), or temporarily shut down an exposed service that cannot be updated.
• Monitor: recently created or modified files in web directories, unknown scheduled tasks, unusual outbound connections, abnormal POST requests in the logs, administrator accounts that appeared for no reason. Keep the logs for analysis.

6. If you cannot update in the short term

PHP is categorical: there are no complete mitigations, only an update is safe. The advisory nevertheless lists measures that reduce exposure to specific attack paths without making the installation safe. For CVE-2026-109618: set memory_limit to -1 in a way applications cannot override (php_admin_value in the FPM pool or the Apache configuration) and lower post_max_size (8M if the application takes no file uploads, 32M otherwise, with upload_max_filesize below it). For CVE-2026-109619: disable session.upload_progress.enabled in php.ini or the FPM pool configuration, then restart every worker, and on PHP 8.5 disable fatal_error_backtraces. Hiding errors with error_reporting, display_errors or @ does not help.

Second layer: a web application firewall. Cloudflare deployed protections against these flaws, named php2shell, about nine hours ahead of public disclosure. Since 21 October at 03:02 UTC they have been enabled by default for every customer of its WAF, free plan included: in the Cloudflare Managed Free Ruleset for the free plan, and in the Cloudflare Managed Ruleset for the Professional, Business and Enterprise plans, where you should confirm that this ruleset is deployed in block mode. Cloudflare insists: the protection comes on top of the fix and does not replace it.

For an application stuck on PHP 8.1 or earlier, three routes remain: obtain a backported package from the host or the distribution (PHP passed the patches in advance to LTS vendors and publishes minimal source backports for 7.4, 8.0 and 8.1), isolate the application behind authentication or a VPN while planning the upgrade, or accelerate that upgrade. A short audit allows the effort to be estimated and the decision to be made.

7. What the GDPR and NIS2 expect from you

Article 32 of the GDPR requires technical measures appropriate to the risk, and the CNIL regards applying critical patches without delay as a minimum. Its 1.7 million euro fine against Nexpublica, in December 2025, targeted precisely vulnerabilities known to the company and fixed only after the data breaches. A site that processes customer or employee data is therefore required to fix a flaw of this level quickly, and to be able to prove it.

The NIS2 directive adds, for the entities concerned, an explicit vulnerability handling obligation. Its French transposition has not yet been adopted as of 21 October 2026, but the companies that will fall under it have every interest in documenting their inventory, their patch dates and the isolation measures taken from today.

8. How AXELITES can help

We maintain and host Magento stores, WordPress and PrestaShop sites and Symfony, Laravel or custom PHP applications for SMEs and mid-sized companies. In response to this alert we offer three interventions: a quick exposure audit (server inventory, PHP versions actually served, applications stuck on an end-of-life branch), the application of the fixes with verification and service restarts, and the setup of monitoring for signs of compromise.

For a Magento store, the free five-business-day audit already covers the PHP version, missing Adobe security patches and risky modules. For applications that cannot be fixed without an upgrade, our third-party application maintenance takes on the planning and delivery of that migration.

Sources and documentation

• PHP: upcoming critical security release notice (20 October 2026)
• PHP: security advisory of 21 October 2026, fixed versions and exposure-reduction measures
• Cloudflare: WAF protections deployed against php2shell (21 October 2026)
• PHP: supported versions
• CERT-EU advisory 2026-018: critical vulnerabilities in PHP
• Drupal PSA-2026-10-20: critical PHP security release
• Adobe Commerce: system requirements
• W3Techs: usage of PHP by version
• Akamai: CVE-2024-4577 exploited one day after disclosure
• CNIL: sanction SAN-2025-015 (Nexpublica)