PHP2Shell: apt upgrade Won't Patch Your aaPanel PHP

On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The press calls them “PHP2Shell” — the PHP project itself doesn’t use that name, so search for the CVE numbers when you check vendor advisories.

Both bugs allow unauthenticated remote code execution on any PHP installation that serves web requests. A proof-of-concept leaked early, so treat any internet-facing PHP as exposed until it’s patched.

This guide is for people who run their own VPS. It covers how to find out whether you’re affected, the common setup where apt upgrade silently does nothing, and what to upgrade to.

The short version

Question	Answer
Who’s affected?	Every PHP build serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed. mod_php is the highest risk.
Fixed versions	8.5.12, 8.4.27, 8.3.36, 8.2.35 (and 8.6.0 RC4)
PHP 8.1 or older?	No official fix from the PHP project. You depend on your distro/vendor backporting it, or you upgrade.
Node.js apps?	Not affected — unless the same server also runs PHP (very common, see below).

Source: the official PHP security advisory.

Step 1: Do you even have PHP?

Plenty of “Node.js-only” servers still run PHP: a leftover WordPress install, phpMyAdmin, or a hosting panel that installed it by default. Check:

# Is any PHP process serving requests?
ps aux | grep -E "php-fpm|php-cgi|apache2|httpd" | grep -v grep

# PHP installed through apt
apt list --installed 2>/dev/null | grep -i php

# PHP installed by aaPanel / BaoTa (outside apt)
ls /www/server/php/ 2>/dev/null

If the first command returns nothing and you don’t need PHP, you’re not exposed to these two bugs. You can stop here — or remove PHP entirely so it can’t come back.

Step 2: The aaPanel / BaoTa trap

This is the case most news coverage skips. On a production VPS running aaPanel that I checked this week, apt showed this:

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...]

Two different PHPs. 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 lists it as a local package, so apt update && apt upgrade never touches it. That server was running a PHP build from December 2022 behind public Nginx on ports 80 and 443 — and no amount of apt upgrading would have changed that.

Check yours:

for v in /www/server/php/*/bin/php; do "$v" -v | head -1; done

Anything below the fixed versions in the table above is vulnerable. Anything on 8.1 or older is vulnerable with no upstream fix.

Step 3: Is it reachable from the internet?

# Is a web server listening publicly?
ss -tlnp | grep -E ":80 |:443 "

# Which Nginx sites pass requests to PHP?
grep -rl "fastcgi_pass\|enable-php" /etc/nginx/ /www/server/panel/vhost/nginx/ 2>/dev/null

If a public site passes requests to a vulnerable PHP, fix it today.

Step 4: Fix it

If you don’t need PHP: stop and disable it. This is the fastest real fix.

# apt-installed PHP-FPM (adjust the version)
sudo systemctl disable --now php8.1-fpm

On aaPanel, stop the PHP service from the panel and remove PHP from any site that doesn’t use it.

If you need PHP:

• apt-installed PHP — upgrade, then confirm the package actually contains the fix rather than assuming it does:

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

  No match means your installed package doesn’t mention the fix yet. Ubuntu 22.04 ships PHP 8.1 by default, which the PHP project no longer patches — you’re relying entirely on Ubuntu’s backport.
• aaPanel / BaoTa — install PHP 8.3 or 8.4 from the App Store, switch each site to it, test, then uninstall 8.1. Before switching, check the version you actually got with /www/server/php/83/bin/php -v. It must be 8.3.36 / 8.4.27 or newer; an older build from the panel’s mirror is still vulnerable.
• Take a snapshot first. Every budget provider (Hetzner, Contabo, DigitalOcean, Vultr) offers server snapshots. Changing PHP versions can break old sites.

Temporary mitigations (not a fix)

If you genuinely can’t upgrade today, the PHP advisory lists mitigations. It’s explicit that they “do not make an installation safe” — they only reduce risk:

• Set session.upload_progress.enabled=0 in php.ini or the FPM pool config (not via ini_set() or .user.ini), then restart every PHP worker.
• Set a low post_max_size — 8M if you don’t need uploads, 32M if you do — and keep upload_max_filesize below it.
• Enforce request size and field-count limits at the web server, e.g. a sensible client_max_body_size in Nginx.
• The advisory also suggests memory_limit=-1 combined with a container/cgroup memory limit. Don’t apply the first half without the second — unlimited PHP memory on a small VPS can take down everything else on it.

Step 5: Check whether you were already hit

The exploit was public before many people patched, and patching doesn’t remove anything an attacker already installed. The PHP advisory doesn’t cover this, so here’s a basic first pass:

# PHP files created or modified since the disclosure
find /var/www /www/wwwroot -name "*.php" -newermt "2026-10-20" -type f 2>/dev/null

# Processes running as the web user that aren't PHP-FPM
ps -u www-data -o pid,etime,cmd 2>/dev/null | grep -v php-fpm
ps -u www -o pid,etime,cmd 2>/dev/null | grep -v php-fpm

# Unexpected cron jobs
crontab -l; ls -la /etc/cron.d /var/spool/cron/crontabs 2>/dev/null

# Outbound connections that aren't SSH/web
ss -tnp state established | grep -vE ":(22|80|443) "

Recently modified files you didn’t touch, or unknown processes under the web user, are a reason to treat the server as compromised: rebuild it from a clean image rather than trying to clean it in place.

If you’re on Node.js

These two CVEs are in the PHP runtime, so a Node.js app behind Nginx isn’t affected by them directly. The real risk for Node.js developers is the PHP you forgot about. If you set up your server with a panel, or followed an old tutorial that installed a LAMP stack, run Step 1.

A clean Node.js VPS doesn’t need PHP at all. If you’re rebuilding, the Hetzner CX22/CX23 setup guide gets you from a fresh Ubuntu server to Node.js, PM2 and Nginx with SSL without installing PHP.

---

Version numbers and mitigations are taken from the PHP security advisory of 21 October 2026. Check it for updates — vendor patch status is changing daily.