PHP2Shell (CVE-2026-109618/109619): check and patch PHP on your VPS

On 21 October 2026 the PHP project released fixes for two remote code execution bugs, CVE-2026-109618 and CVE-2026-109619, widely called PHP2Shell. Both can be triggered by an unauthenticated web request, the PHP security team rates both 9.2 out of 10 (CVSS v4), and Cloudflare and watchTowr reported exploitation attempts the same day. If PHP on your server answers web requests, update it today.

This guide shows how to check what you have, update it on each distribution we offer, and make sure the running PHP is the fixed one. VPSNine's own site and panel don't run PHP, so nothing on our side is affected; the PHP on your server is yours to patch, and the commands below do it.

What's affected#

Any PHP that serves web requests: PHP-FPM (what our LEMP and WordPress apps use), Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project calls mod_php the highest risk. A PHP that only runs command-line scripts isn't reachable from the web, but it comes from the same packages and gets fixed by the same update.

The fixed releases from the PHP project are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 get no release, only source patches, and 7.3 and older get nothing at all.

The catch: distributions don't usually move to the new upstream release. They patch the version they shipped, so php -v can still print 8.3.6 on a fully fixed Ubuntu 24.04 server. Judge by the package version, not by php -v.

If you use our LEMP or WordPress app#

Both install PHP-FPM from your distribution's own repositories, never from a third-party repository, so the distribution sections below apply.

LEMP and WordPress installs made after this guide was published also turn on automatic security updates and restart PHP-FPM when an update replaces it. You can tell by whether this file exists:

ls -l /usr/local/sbin/vps9-php-fpm-restart

If it does, the fix installs itself within a day of your distribution publishing it, and PHP-FPM restarts afterwards. Check anyway with the steps below. If it doesn't, the server was set up before we added this: update by hand now, then turn on automatic security updates.

Ubuntu and Debian#

See which PHP packages you have and their versions:

dpkg -l 'php*' 'libapache2-mod-php*' | grep '^ii'

Compare the version of phpX.Y-common (or phpX.Y-fpm) with the fixed package for your release. These come from Ubuntu's and Debian's own security trackers, checked on 21 October:

Ubuntu 22.04's PHP 8.1 is past its end of life upstream, but Canonical patched it, so a 22.04 server is covered. Debian 12 is now in its long-term support phase; the fix arrives from the same security archive as before.

To compare without reading version strings by eye (Ubuntu 24.04 shown; use your release's package and version):

dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.3-common)" ge 8.3.6-0ubuntu0.24.04.13 && echo patched || echo "NOT patched"

Update everything, which is the simplest and safest:

apt update
apt upgrade

If you can't take every update right now, upgrade only the installed PHP packages:

apt update
apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null)

Then restart whatever runs PHP. The fpm package usually restarts itself, but a restart costs a second and removes the doubt:

systemctl restart 'php*-fpm.service'
systemctl restart apache2   # only if you use Apache with mod_php

AlmaLinux and Rocky Linux#

See what's installed, and whether your repositories already offer a fix for these CVEs:

rpm -q php-fpm php-common
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619

On version 9, PHP comes in module streams; dnf module list php shows the one you're on. AlmaLinux and Rocky rebuild Red Hat's packages and publish after Red Hat does. On 21 October, Red Hat's tracker listed a fix for RHEL 8 only, not yet for 9 or 10, so an empty updateinfo list is expected for a little while. Check again daily, and use the stopgaps further down until it lands. When it does:

dnf upgrade --refresh 'php*'
systemctl restart php-fpm
systemctl restart httpd   # only if you use Apache with mod_php

rpm -q --changelog php-common | grep -m1 CVE-2026-109618 confirms that the installed package carries the fix.

Fedora#

Fedora ships PHP's own releases, so php-fpm at 8.4.27, 8.5.12 or later is fixed. New builds go to updates-testing before stable; we hadn't seen them reach stable on 21 October. To check and update:

rpm -q php-fpm
dnf upgrade --refresh 'php*'
systemctl restart php-fpm

If dnf finds nothing newer, look up php on bodhi.fedoraproject.org to see where the update has got to.

Arch Linux#

Arch has had php 8.5.12 in its extra repository since 21 October. Arch doesn't support partial upgrades, so update the whole system:

pacman -Syu
pacman -Q php php-fpm php-legacy 2>/dev/null
systemctl restart php-fpm

If you use php-legacy, check its version against the fixed releases too. Our one-click apps don't install PHP on Arch, so this only applies to PHP you installed yourself.

Make sure the fix is running#

An updated package doesn't help until the PHP processes restart. Check that PHP-FPM started after the update (the unit is php8.3-fpm on Ubuntu 24.04, php-fpm on the Red Hat family):

systemctl show -p ActiveEnterTimestamp php8.3-fpm

Then check that it isn't still running files the update replaced. No output is what you want:

grep -E ' /(usr|lib|lib64)/[^ ]* \(deleted\)$' /proc/$(systemctl show -p MainPID --value php8.3-fpm)/maps

If you see lines, restart PHP-FPM again. Where needrestart is installed (it is on Ubuntu server images), needrestart -r l lists every service still running old code.

Third-party PHP repositories#

Many servers run PHP from Ondřej Surý's packages (the ppa:ondrej/php PPA on Ubuntu, packages.sury.org on Debian) or from Remi's repository on the Red Hat family, often to get a PHP version the distribution doesn't ship. Those follow PHP's own releases, so the fixed versions are the upstream ones above.

Check where your PHP comes from and which version is installed:

apt policy php8.3-fpm             # Ubuntu and Debian: the repository is shown next to each version
dnf info --installed 'php*-fpm'   # Red Hat family: see "From repo"

A version like 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 is fixed; its upstream part, 8.3.36, is what counts. Update the same way as above, then restart PHP-FPM. Remember that the repository, not your distribution, is now the one responsible for your PHP's security fixes.

PHP 7.4, 8.0 and 8.1#

The PHP project published source patches only for these versions, so whether you're fixed depends on who builds your packages:

• From your distribution (Ubuntu 22.04's 8.1, for example): the distribution patches it; follow its section above.
• From a third-party repository: look for the CVE in the package changelog. apt changelog php8.1-fpm | grep CVE-2026-109618 on Ubuntu and Debian, rpm -q --changelog php81-php-fpm | grep CVE-2026-109618 for Remi's packages. No mention means no fix.
• Built yourself: apply the backports from PHP's advisory and rebuild.

If none of those applies, plan the move to PHP 8.2 or newer now. In the meantime, keep the site behind the stopgaps below, or take it offline if it holds anything that matters.

Stopgaps if you can't update yet#

PHP's advisory lists settings that reduce the risk. They don't make PHP safe, and you should only use them until the update is in:

• session.upload_progress.enabled = 0, and on PHP 8.5 fatal_error_backtraces = 0, in the php.ini that PHP-FPM reads (/etc/php/8.3/fpm/php.ini on Ubuntu 24.04, /etc/php.ini on the Red Hat family).
• A lower post_max_size, so large crafted request bodies are refused.

Restart PHP-FPM after the change. A web application firewall in front, such as Cloudflare's free plan, blocks the known exploit requests, but only for traffic that goes through it.

If you think a server was attacked before it was patched, What to do if your server is compromised covers what to check and why rebuilding is the safe fix.

Sources#

• PHP's announcement and advisory: php.net
• Ubuntu: CVE-2026-109618 and PHP2Shell fixes available
• Debian: security tracker
• Tenable's frequently asked questions and Wiz's write-up