PHP2Shell and HTTP2Shell: Is Your Server Patched? 6 Checks (Tested)

# php -v

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)

Reading it. 8.3.6 looks hopeless next to the fixed 8.3.36. On Ubuntu, it isn’t. Linux distributions keep the version number their release shipped with and backport security fixes into it, so the number on its own tells you almost nothing. Notice the build date too: 19 October, two days before the official PHP release, because distributions get fixes under embargo. Advice like “make sure your build is from 21 October or later” would wrongly flag this server. The next step is the real test.

Every Debian or Ubuntu package ships a changelog. If the fix is in, the CVE number is in there.

# dpkg -s php8.3-cli | grep ^Version
# zgrep -E "CVE-2026-109618|CVE-2026-109619" /usr/share/doc/php8.3-cli/changelog.Debian.gz

Version: 8.3.6-0ubuntu0.24.04.13
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
    - CVE-2026-109618
    - CVE-2026-109619

Reading it. Both CVE numbers are listed against -0ubuntu0.24.04.13: this server is patched, whatever php -v says. No output means the fix isn’t installed yet: run sudo apt update && sudo apt upgrade, then restart PHP (sudo systemctl restart php8.3-fpm or apache2). Change 8.3 to your version. On Red Hat-family systems the same idea is rpm -q --changelog php | grep CVE-2026-109618 (not tested here). If you installed PHP from php.net or a third-party repository, the version number is meaningful: compare it with the table.

The third flaw has no patch yet, and it only works if session upload progress is on. Almost no site uses it, and it’s on by default.

# php-fpm8.3 -i | grep upload_progress.enabled
# echo "session.upload_progress.enabled = Off" | sudo tee /etc/php/8.3/fpm/conf.d/99-php2shell.ini
# php-fpm8.3 -i | grep upload_progress.enabled
# sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm

session.upload_progress.enabled => On => On
session.upload_progress.enabled = Off
session.upload_progress.enabled => Off => Off
NOTICE: configuration file /etc/php/8.3/fpm/php-fpm.conf test is successful

Reading it. A small file in conf.d overrides the setting without editing php.ini, so a future PHP update won’t undo it. -t checks the configuration before the restart, so a typo can’t take the site down. Using Apache’s mod_php instead of PHP-FPM? Put the same file in /etc/php/8.3/apache2/conf.d/ and restart apache2. The command-line PHP has its own folder (cli/conf.d); it doesn’t serve web pages, so it matters less.

Most WordPress sites can’t run any of the above. In your WordPress admin, go to Tools → Site Health → Info and open Server.

Web server = Apache
PHP version = 8.5.12 (Supports 64bit values)
PHP SAPI = cgi-fcgi

Reading it. That’s this site: PHP 8.5.12, exactly the fixed release, so our host had already patched it. On shared hosting the host maintains PHP, and the version shown is usually upstream PHP, so compare it straight against the table. Two things people get wrong: updating WordPress, plugins or themes does not fix PHP2Shell (the bug is underneath them), and a site on PHP 8.1 or older will never get a fix, so switch to a supported PHP version in your hosting control panel. You can’t usually see the upload-progress setting from here: if in doubt, ask your host whether they’ve applied PHP’s mitigation for CVE-2026-115560.

The Brotli bug lives in a shared library, so one package update fixes every program that uses it. Check it the same way as PHP:

# dpkg -l "libbrotli*" | grep ^ii
# zgrep CVE-2026-111497 /usr/share/doc/libbrotli1/changelog.Debian.gz

ii  libbrotli1:amd64 1.1.0-2ubuntu0.1 amd64        library implementing brotli encoder and decoder (shared libraries)
    - debian/patches/CVE-2026-111497.patch: Detect and report invalid stream
    - CVE-2026-111497

Reading it. Patched. The catch is that many programs bundle their own copy of Brotli instead of using the system one, and the system update doesn’t touch those: Node.js (check node --version against the table), the Python brotli package (pip show brotli, needs 1.2.1), .NET, Envoy and Istio, Bun, and anything compiled into a single binary. Those each need their own update.

A container carries its own Node.js and libraries. The tag name (node:24-slim) stays the same while the contents change, so ask the image itself:

# docker pull node:24-slim
# docker run --rm node:24-slim node --version

v24.22.2

Reading it. 24.22.2 is newer than the fixed 24.22.1, so a freshly pulled image is safe. The risk is the old copy already on your server: a container started last month keeps running last month’s Node until you pull and recreate it (docker compose pull && docker compose up -d). Images you build yourself need rebuilding too. A software bill of materials (SBOM) made before 21 October will list the old versions.