PHP2Shell and Proxmox: the host is fine, the PHP apps in your guests need patching

PHP2Shell should not affect Proxmox products themselves. Proxmox VE and Proxmox Mail Gateway are written in Perl, Proxmox Backup Server and Datacenter Manager in Rust, and a Proxmox staff member said so on the Proxmox forum on 21 October 2026. The exposure sits in your guests: any LXC container or VM that serves PHP needs the 21 October 2026 fix for CVE-2026-109618 and CVE-2026-109619.

Many homelab and small business Proxmox hosts run PHP web apps in their guests, and some of those apps face the internet. This post covers the two bugs, the Proxmox answer, and a routine to check and patch each guest.

What PHP2Shell is

PHP2Shell is the name for two PHP vulnerabilities, each rated CVSS v4.0 9.2 in the PHP project's notice of 20 October 2026. Both can allow unauthenticated remote code execution.

According to the PHP security advisory, CVE-2026-109618 comes from out-of-memory handling that can interrupt PHP while internal request data is only partly initialized. CVE-2026-109619 is request state that survives after its memory is freed, so a later request on the same worker can use it.

PHP says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where a demonstrated exploit fires before any application code runs. The watchTowr write-up adds that the command line binary can be a different version from the one serving web requests, so check the PHP that answers HTTP.

PHP announced the coming release on 20 October, the day watchTowr says details leaked, and shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 at 14:00 UTC. Amazon's threat intelligence team saw its first exploitation attempt on 17 October, four days before disclosure, and the first public proof of concept exploits appeared early on 21 October, before the release, with more within hours of it. watchTowr observed exploitation of both CVEs in the wild on 21 October.

What Proxmox said

On Wednesday 21 October a user on the Proxmox forum asked whether Proxmox runs PHP and whether to shut systems down. Proxmox staff member sterzy answered that the products are built with Perl or Rust, so "you should not be impacted by php2shell". Proxmox does host services that use PHP, such as the Proxmox VE wiki, and rolled the patches out across them after release.

On Friday 23 October another user found /etc/apparmor.d/abstractions/php on freshly installed cluster nodes. Staff explained that it is an AppArmor abstraction used by profiles, not PHP. They added that if you installed PHP on the host yourself, or host it inside a VM or container, you can still be affected.

Where PHP sits on a Proxmox host

Look at what you run in your guests. Several common self-hosted apps are PHP applications by their own documentation: Nextcloud 36 supports PHP 8.3 to 8.5, WordPress recommends PHP 8.3 or newer, the Zabbix frontend requires PHP 8.0 to 8.5, and LibreNMS needs PHP 8.4 or newer and runs it through PHP-FPM. If you split services into separate containers, as in the LXC vs VM vs Docker guide, you may have several of these, each with its own PHP.

Step 1: take a snapshot first

Give yourself a rollback point before you upgrade anything. On storage that supports snapshots (ZFS, LVM-thin, Ceph):

pct snapshot 101 pre-php2shell
qm snapshot 200 pre-php2shell

If your storage cannot snapshot, run a backup to Proxmox Backup Server first. The Proxmox backup strategy for 2026 covers how to set that up.

Step 2: find PHP in every guest

List your guests on the host:

pct list
qm list

Then check each running container for PHP and Docker in one loop:

for id in $(pct list | awk 'NR>1 && $2=="running" {print $1}'); do
  echo "== CT $id"
  pct exec "$id" -- sh -c 'command -v php >/dev/null && php -v | head -n 1; command -v dpkg >/dev/null && dpkg -l | grep -E "^ii +(php|libapache2-mod-php)" | awk "{print \$2, \$3}"; command -v docker >/dev/null && docker ps --format "{{.Names}} {{.Image}}"'
done

For VMs with the QEMU guest agent installed, qm guest exec 200 -- php -v runs the same check. Without the agent, log in to the VM. For Docker containers, run docker exec <name> php -v on the app containers the loop lists.

Step 3: patch through the distribution

On Debian guests, upgrade the PHP packages and restart the service that runs PHP:

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt upgrade
systemctl restart php8.4-fpm

On Debian 12 the service is php8.2-fpm. Restart apache2 instead if the app uses mod_php. The Debian security tracker, which I checked on 25 October 2026, lists these fixed packages for both CVEs:

• Debian 13 trixie: php8.4 8.4.27-1~deb13u1, from DSA-6574-1
• Debian 12 bookworm: php8.2 8.2.35-1~deb12u1, from Debian LTS advisory DLA-4848-1

Confirm with dpkg -l 'php8.4*' | grep ^ii. Debian's numbers match upstream this time. Qualys notes that distribution backports may keep older upstream version numbers, so on Ubuntu, Alpine or anything else, check your vendor's advisory instead of looking for 8.4.27. If PHP came from a third-party repository, the Debian tracker does not cover it; php -v must show a fixed release.

For Docker apps, pull the updated image and recreate the container with docker compose pull && docker compose up -d, then run php -v inside it again. If the maintainer has not published a fixed image yet, the next section applies.

PHP 8.1 and older no longer get releases from the PHP project. PHP published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship fixed packages. Otherwise, upgrade the app to a supported PHP branch.

If you cannot patch today

PHP lists settings that reduce specific attack paths, such as session.upload_progress.enabled=0 and an enforced memory_limit=-1, and states that none of them make an installation safe. Amazon suggests blocking multipart file uploads if the app allows it.

For a homelab, the simpler fix is to take the app off the internet until it is patched. Remove the port forward, restrict it with an access list on your reverse proxy (see Nginx Proxy Manager vs Traefik on Proxmox), and reach it over a VPN in the meantime.

If the app was exposed, check the logs too. Amazon recommends searching POST requests for the string PHP_SESSION_UPLOAD_PROGRESS and starting any review from 17 October, not from the disclosure date.