Critical PHP vulnerabilities of October 2026: what to do now

Two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, can under certain conditions allow remote code execution on a server, without authentication. The PHP project released the fixes on 21 October 2026 and CERT-FR, the French government CERT, issued an alert the same day. All branches are affected, from PHP 5 to PHP 8.5. This guide explains what is happening, who is affected and how to fix it, including when the update cannot be done straight away.

It is aimed at executives, CIOs and application owners whose website, online shop or business application runs on PHP: WordPress, Drupal, PrestaShop, Magento, Symfony, Laravel or custom development. The starting point is simple: the flaw is in PHP itself, not in your application. Updating WordPress or a plugin is not enough; PHP has to be updated on the server.

What happened

On 20 October 2026, the PHP security team announced two critical vulnerabilities and the release of their fixes for the next day, at 4 pm Paris time. The vulnerability identifiers were already circulating on forums: according to the PHP Foundation, the release was brought forward from 22 to 21 October because of this leak.

On 21 October, PHP released four fixed versions and two detailed security advisories. The same day, CERT-FR published alert CERTFR-2026-ALE-014, and the US Cybersecurity and Infrastructure Security Agency (CISA) issued an alert calling for the fixes to be applied immediately, starting with internet-facing servers.

When it published its alert, CISA was not reporting active exploitation. But how the vulnerabilities work is now publicly described, in PHP’s own advisories: the update should be handled as an emergency, not as maintenance to be scheduled.

The two vulnerabilities, in plain terms

Both vulnerabilities affect the way PHP prepares and then cleans up each web request. An attacker can trigger them with specially crafted HTTP requests, before your application’s code even runs.

• CVE-2026-109618: memory corruption after running out of memory. If a request hits PHP’s memory limit at the wrong moment, half-initialised internal data is then treated as valid. On Apache with mod_php, PHP states that code execution has been demonstrated over HTTP with default settings.
• CVE-2026-109619: stale state reused. A fatal error at the wrong moment can leave internal state pointing to the memory of a previous request; the next request handled by the same process reuses it. Code execution has been confirmed on mod_php, and the path through upload progress tracking (session upload progress) has also been validated on PHP-FPM.

PHP rates both vulnerabilities 9.2 out of 10 (CVSS 4.0), the critical level. No authentication is required. The attack needs precise conditions and sometimes several attempts, which does not make it any less serious: an exposed server receives requests from anyone, continuously.

Who is affected

According to PHP, every installation that serves web requests is affected, whatever the execution mode: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. The risk is highest with mod_php.

Versions based on the CERT-FR alert and PHP’s advisories; branch schedule based on php.net.

This means every website and application built on PHP is affected: CMSs (WordPress, Drupal, Joomla), e-commerce (PrestaShop, Magento), frameworks (Symfony, Laravel) and custom applications. Not forgetting acceptance or pre-production environments reachable from the internet, old sites thought to be shut down, internal tools (extranet, webmail, back office) and software that embeds PHP without saying so, which CISA mentions explicitly.

Fixing it: update PHP, then restart

The only complete fix is updating PHP. PHP’s advisories say it repeatedly: interim measures reduce exposure, they do not make a server safe.

• Take inventory. List every server, container and hosting account that runs PHP, with its version and execution mode (PHP-FPM, mod_php…). CISA puts this step first: a forgotten server remains vulnerable.
• Deal with internet-facing systems first. Public sites, APIs, back offices reachable online, then the rest.
• Install the fixed version through the right channel. Packages from your Linux distribution or the repository you use, a Docker image rebuilt on a fixed base image, or an update by your hosting provider. PHP says distributions and long-term support vendors received the fixes in advance; some third-party repositories do not publish on the same day.
• Restart every PHP process. PHP-FPM, Apache, and long-running processes (FrankenPHP in worker mode, message queue consumers, Laravel Octane…). As long as a process runs with the old version loaded in memory, the server remains vulnerable.
• Check the version actually being served. Not just the command-line one: PHP-FPM and the Apache module can run a different version from the php command.

On a Debian or Ubuntu server with PHP-FPM, the sequence looks like this (adapt the branch number to your installation):

# Installed versions: command line and PHP-FPM
php -v
php-fpm8.3 -v

# Update PHP packages from the configured repository
sudo apt update
sudo apt install --only-upgrade 'php8.3*'

# Restart PHP processes
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # if PHP runs as mod_php

On shared or managed hosting, the hosting provider updates PHP. Check the version in use in your customer area, ask the provider to confirm that the 21 October fixes have been applied, and move to a supported branch if your site still runs on 8.1 or earlier. If a provider handles the application maintenance of your sites, these steps are theirs to carry out: ask them for the status of each server.

If you cannot update straight away

CERT-FR and PHP provide interim measures. They do not replace the update, and each covers only part of the risk.

• Disable upload progress tracking. session.upload_progress.enabled = Off in php.ini, or php_admin_flag[session.upload_progress.enabled] = off in the PHP-FPM pool, then restart every PHP process. According to CERT-FR, this only reduces the attack surface for one of the two vulnerabilities.
• On PHP 8.5: fatal_error_backtraces = 0, then restart. PHP says this setting cuts off the confirmed exploitation path of CVE-2026-109619 on that version.
• Filter multipart requests. CERT-FR recommends blocking, for example with a web application firewall (WAF), requests whose Content-Type header is multipart, or failing that, monitoring them. Be aware that this breaks file upload forms.
• Limit the size and complexity of requests at web server or proxy level (size, number of fields, parts and headers), as detailed in PHP’s advisory on CVE-2026-109618.

; php.ini (configuration loaded when PHP starts)
session.upload_progress.enabled = Off

; PHP-FPM pool: a setting the application cannot change
php_admin_flag[session.upload_progress.enabled] = off

PHP 8.1 and earlier

Branches 5.x to 8.1 no longer receive updates from the PHP project, and no official release fixes these vulnerabilities. PHP publishes minimal patches for 7.4, 8.0 and 8.1, to compile yourself, and some distributions or long-term support vendors provide fixed packages.

CERT-FR recommends isolating the affected servers, then migrating to a supported version. CISA goes further: take PHP systems that cannot be fixed offline until they are fixed. For an older application, now is the time to plan the upgrade: our guide on the end of support for PHP 8.2 details the method, and points out that the 8.2 branch itself will no longer be fixed after 31 December 2026.

After the update: check and monitor

• Every server in the inventory serves a fixed version, checked from the web server and not just on the command line.
• Every PHP process has been restarted.
• Acceptance and pre-production environments, and old sites, have been fixed or taken off the internet.
• Logs are being monitored: CISA recommends watching for PHP processes that launch a shell or download tools.
• Upload progress tracking stays disabled if you do not use it: PHP recommends this even after updating.
• The date of the update and the installed versions are recorded, for your customers or for an audit.

If you notice abnormal behaviour, or if an exposed server could not be fixed in time, treat it as an incident: isolate it, keep the logs and get support, for example from a provider found through Cybermalveillance.gouv.fr, the French government’s assistance platform. If personal data may have been exposed, Article 33 of the GDPR requires notifying the supervisory authority (the CNIL in France), where feasible within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals.

Frequently asked questions

A fix to apply everywhere, not just in production

These two vulnerabilities do not require changes to your application: they require knowing where PHP runs, updating it everywhere and checking that the new version is actually in service. A few steps per server, provided you know all your servers.

If you lack visibility over your servers, or if your applications still run on an end-of-life PHP version, iones’ nearshore team provides application maintenance and web infrastructure security: inventory, updates, version migration. Write to us to review your estate.