PHP CVE-2026-109618 and CVE-2026-109619: remote code execution, what to do

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities, rated 9.2 out of 10 (CVSS v4.0). They let an unauthenticated attacker run code on the server with a single HTTP request, before your application code even starts. If your server runs a PHP site (WordPress, Laravel, Symfony, a custom CMS…), it is affected.

In short: upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later), then restart every PHP process.

What the two flaws do

CVE-2026-109618: corruption on out-of-memory

When PHP hits its memory limit while it is setting up a request, it can stop with some internal data only half initialised. End-of-request cleanup then treats that data as valid. An attacker who triggers the out-of-memory condition on purpose, for example with a large POST body, can turn this into code execution.

CVE-2026-109619: state that survives between requests

A PHP worker handles many requests in a row. Some request-owned data can stay in memory after it has been freed and be used by the next request on the same worker before it is reset. Again, an attacker can turn this into code execution.

Who is exposed?

According to the official PHP advisory, every installation serving web requests is affected:

• PHP-FPM behind Nginx or Apache;
• Apache with mod_php, the most exposed setup (an unauthenticated attack has been demonstrated);
• php-cgi, FrankenPHP, LiteSpeed.

No account, no vulnerable plugin and no bug in your code is needed: the server only has to be reachable.

Fixed versions

If you still run PHP 8.1 or older, now is the time to migrate: those branches no longer get official releases.

Check your server

PHP version used on the command line:

php -v

Careful: the website may use a different version than the CLI. List installed versions and running PHP-FPM services:

ls /etc/php/ 2>/dev/null
systemctl list-units --type=service | grep -i php

On Debian or Ubuntu, see whether an update is available:

sudo apt-get update && apt list --upgradable 2>/dev/null | grep -i php

Distributions often fix the flaw without changing the main version number (backport). In that case, check the package changelog:

apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"

On Red Hat, AlmaLinux or Rocky Linux:

rpm -q --changelog php-cli | grep -E "CVE-2026-10961[89]"

Fix it

1. Upgrade the PHP packages (sudo apt-get upgrade or sudo dnf upgrade), or rebuild with the fixed version.
2. Restart every PHP process: sudo systemctl restart php8.3-fpm (adjust the version) and, with mod_php, sudo systemctl restart apache2. Without a restart, the old code stays in memory.
3. Check the version actually served again, for example with a temporary phpinfo() page that you delete right away.

If you cannot upgrade right now

The PHP team suggests settings that reduce the risk without removing it. Upgrading is the only complete fix.

• Against CVE-2026-109619: turn off upload progress in php.ini or the FPM pool config (not with ini_set() or .user.ini), then restart:

session.upload_progress.enabled = 0

• PHP 8.5 only: also set fatal_error_backtraces = 0.
• Against CVE-2026-109618: lower the maximum request size, for example post_max_size = 8M if you have no file uploads (32M otherwise), keep upload_max_filesize below it, and cap request size in Nginx (client_max_body_size).

On 23 October PHP also recommended keeping session.upload_progress.enabled = 0 until the next release, even after upgrading, to close a rare variant (CVE-2026-115560).

Why act fast

An unauthenticated code execution flaw present on millions of servers is quickly hunted by bots scanning the Internet. Unpatched servers risk a backdoor (webshell), a cryptominer or a stolen database. If your server stayed exposed for several days, also look for signs of compromise: see our guide How to find a webshell on a Linux web server.

How FounderMode helps

The FounderMode agent inventories the software installed on your servers and checks it every day against public vulnerability databases. Your daily report lists the vulnerable versions to fix first, and the antivirus looks for webshells and miners dropped after an attack.

Frequently asked questions

Is my shared hosting affected?

Yes if your sites run on PHP. The host has to apply the fix: check its status page or open a ticket.

Do I need to update WordPress or Laravel?

No, the flaw is in PHP itself, not in the application. You need to upgrade PHP and restart its processes.

Are the temporary settings enough?

No. They reduce the known attack paths. Only the fixed version fully protects you.

Sources: PHP security announcement, 21 October 2026, follow-up advisory, 23 October 2026, CloudLinux advisory.