On 21 October the PHP project shipped emergency releases for CVE-2026-109618 and CVE-2026-109619 ("PHP2Shell" in the press — PHP itself doesn't use that name). Both allow unauthenticated remote code execution on any PHP that serves web requests: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. A proof-of-concept leaked early.
Fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 8.1 and older get no official fix.
Most coverage stops there. Here's the part that bit a server I checked this week.
The aaPanel / BaoTa trap
apt on that box showed two PHPs:
bt-php81/now 8.1.13 amd64 [installed,local]
php8.1-cli/now 8.1.31-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,upgradable to: 8.1.32...]
The one actually serving the websites was the panel's:
php-fpm: master process (/www/server/php/81/etc/php-fpm.conf)
PHP 8.1.13 (cli) (built: Dec 1 2022 08:28:57) (NTS)
aaPanel compiles its own PHP into /www/server/php/<version>/. apt sees it as a local package and apt upgrade never touches it. A December 2022 PHP build, behind public Nginx on 80/443 — and no amount of apt upgrading would have changed that.
Check your server in 2 minutes
# Anything serving PHP?
ps aux | grep -E "php-fpm|php-cgi|apache2|httpd" | grep -v grep
# apt-installed PHP
apt list --installed 2>/dev/null | grep -i php
# Panel-installed PHP (aaPanel/BaoTa)
for v in /www/server/php/*/bin/php; do "$v" -v | head -1; done
Anything below the fixed versions is vulnerable.
Fix
-
Don't need PHP? Stop and disable it (
sudo systemctl disable --now php8.1-fpm, or stop it in the panel). Many "Node.js-only" servers still run PHP from an old WordPress, phpMyAdmin, or a panel default. -
apt PHP: upgrade, then verify the package actually mentions the fix instead of assuming:
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]" -
aaPanel: install PHP 8.3/8.4 from the App Store, check
/www/server/php/83/bin/php -vis ≥ 8.3.36 / 8.4.27, switch each site, then remove 8.1. - Snapshot the server first.
Patching doesn't remove anything an attacker already dropped, so also look for PHP files modified since 20 Oct and processes running as your web user that aren't PHP-FPM.
Full guide — reachability checks, the official temporary mitigations (and why one of them can take down a small VPS), and a compromise checklist: vpsfor.dev →
Top comments (0)