Patch the October 2026 PHP remote code execution bugs

On 21 October 2026 the PHP project fixed two critical bugs, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10. An attacker can use them to run their own code on your server just by sending it a web request, without logging in. Any server that runs PHP websites is affected, whichever way PHP is connected to the web server (PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed). PHP says the risk is highest with mod_php.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On an unmanaged VPS we cannot update PHP for you, so please do it now.

1. Find out which PHP you run

$ php -v
$ dpkg -l 'php*' | grep ^ii

$ php -v
$ rpm -qa 'php*'

A server can have more than one PHP version installed, so note every one the list shows. php -v only shows the command-line PHP; your sites may run another version through PHP-FPM or a control panel.

2. Check for the fix, not the version number

Linux distributions often add the fix to their existing PHP package without changing its version number, so php -v can show an old number even after the fix. Our Ubuntu 24.04 test server still showed 8.3.6 once it was fixed. Look for the CVE number in the package's change list instead:

$ for f in /usr/share/doc/php*-common/changelog.Debian.gz; do echo "$f: $(zgrep -ohE 'CVE-2026-10961[89]' "$f" | sort -u | tr '\n' ' ')"; done

$ for p in $(rpm -qa '*php*-common*'); do echo "$p: $(rpm -q --changelog $p | grep -oE 'CVE-2026-10961[89]' | sort -u | tr '\n' ' ')"; done

Each line is the changelog of one PHP package. Both CVE numbers mean the fixes are recorded for that package. If either is missing, compare the package version with your distribution's security advisory. Check every PHP version your sites use; these commands do not cover PHP from a control panel, a container or your own build.

3. Take a snapshot, then update

Take a snapshot first, so you can roll back if the update breaks your site. Then update:

$ sudo apt update
$ sudo apt upgrade

$ sudo dnf upgrade 'php*'

As of 22 October, fixed packages are available for Debian 12 and 13, Ubuntu 22.04 and 24.04, and AlmaLinux 8, 9 and 10, where they began rolling out on 21 October and some mirrors may lag. For RHEL and Rocky Linux, check the security advisory for your exact PHP version before assuming it is fixed. If dnf finds no PHP update, run sudo dnf clean metadata and check again, and use step 5 in the meantime.

On a control panel, update through the panel. Plesk has released fixed PHP 7.4 to 8.5 builds for supported Linux setups; check that yours received them. The PHP that runs the Plesk panel itself is patched separately. On cPanel, update both cPanel & WHM and EasyApache 4.

4. Restart PHP and check it

The old code keeps running until every service that runs PHP restarts. In our tests the Ubuntu and AlmaLinux packages restarted PHP-FPM and Apache by themselves, but restart anyway, because panel builds and self-compiled PHP do not:

$ sudo systemctl restart php8.3-fpm
$ sudo systemctl restart apache2

$ sudo systemctl restart php-fpm
$ sudo systemctl restart httpd

Use your version in the service name, and skip the services you do not run. Then check that PHP restarted after the update:

$ systemctl show -p ActiveEnterTimestamp php8.3-fpm

The time it shows must be later than the update. Then repeat the check from step 2: a restart alone does not prove the fix is installed.

5. If you cannot update yet

PHP lists settings that block the known ways in. They are not a fix: in PHP's words, they "do not make an installation safe". Save these three lines in a new file and restart PHP. Settings made with ini_set() or .user.ini do not count.

session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 4M

On Ubuntu and Debian, put the file in /etc/php/8.3/fpm/conf.d/ for PHP-FPM or /etc/php/8.3/apache2/conf.d/ for mod_php, using your version number. On RHEL-based systems, put it in /etc/php.d/. In our tests the settings changed nothing until PHP restarted. Use post_max_size = 32M if your site takes larger uploads, and keep upload_max_filesize below it. On PHP 8.5, also set fatal_error_backtraces = 0.

PHP also advises removing the memory limit, set in a way your site cannot change back. For PHP-FPM, add this line to the pool file, such as /etc/php/8.3/fpm/pool.d/www.conf:

php_admin_value[memory_limit] = -1

For mod_php, put php_admin_value memory_limit -1 in your Apache site config. Restart PHP-FPM or Apache after either change. In our tests a site could no longer lower the limit with ini_set(). Without a limit, one heavy request can use a lot of RAM, so PHP suggests a container or cgroup memory limit as a safety net. The full list is in the PHP advisory.

6. Check for signs of trouble

Cloudflare reported attack traffic aimed at these bugs on 21 October, after details leaked before the release. Whether attacks succeeded is harder to know. If your server ran an unfixed PHP while reachable from the internet, check it for a break-in instead of assuming the update fixed everything. Look for files in your web folders that you did not put there, new cron jobs, unknown processes, and unusual load or outgoing traffic.

Quick reference

Where to go next

Turn on automatic security updates if your setup allows it, remove PHP versions you no longer use, and keep your CMS, plugins and themes up to date.