PHP2Shell fixed versions: apt, dnf, cPanel, containers

The fixed builds

The build numbers are per branch, not per release: 8.3.36 is the patched build of the 8.3 line, not a new major version. 8.2 is still in security support — until 31 December 2026 — and gets 8.2.35. Anything on 8.1 or older has no package: the branch is closed and only a source backport exists.

Read your package manager, not the website

Distribution packages carry a suffix that is easy to misread: 8.2.35-0+deb12u1, 8.3.36-1.el9, 8.3.36-1ubuntu1. The PHP version is the first three numbers; the rest is the packager's own revision. Compare only that part.

# Debian / Ubuntu — what is installed and what is available
dpkg -l | grep -E 'php[0-9.]*-(fpm|cli)'
apt-cache policy php8.3-fpm

# RHEL / Alma / Rocky
rpm -q php-fpm
dnf info php-fpm

# Alpine / containers
apk info -v | grep php

If apt-cache policy shows the installed version below the candidate, the update exists and has not been applied. If both are old, the repository you use has not published the fix yet — check the vendor's own advisory rather than waiting: distributions and LTS vendors received these patches in advance, but a stale mirror or a pinned version can hold you back.

Panels, containers and Homebrew

• cPanel / WHM ships its own EA-PHP packages (/opt/cpanel/ea-php83). They are updated through the panel's own updater, not through the system package manager. Where to see the version →
• Plesk keeps PHP handlers per domain and updates them with its own package set; the version a domain uses is in “PHP Settings”, not in the panel default.
• Docker images are immutable: pulling a new tag does nothing until you rebuild and redeploy the container. docker exec app php -v shows what the running container has.
• Homebrew and other build-from-source setups need a formula update plus a service restart; the old binary stays in the keg until you switch.

Prove that the patched build is the one serving traffic

1. Rebuild or update. Whatever installs the package — apt, dnf, the panel updater, the image build.
2. Restart the workers. systemctl reload php8.3-fpm (or the panel's restart). A reloaded binary means nothing while the old master keeps its children.
3. Check the running process, not just the CLI. ls -l /proc/$(pgrep -o -f 'php-fpm: master')/exe and the start time of the pool's children.
4. Check the branch the site uses. A server can hold four branches; the site runs one. grep -r fastcgi_pass /etc/nginx or the panel's PHP selector answers which.
5. Confirm from outside. If the site publishes its version, an external check now shows a fixed build; if the version is hidden, the check says “not disclosed” — expected, and not a failure.

Three ways this goes wrong

Updated the wrong branch. The server has 8.1, 8.2 and 8.3 installed; the site is on 8.2. Patching 8.3 changes nothing and looks like success in the terminal.

Rebuilt the image, did not redeploy. The new image sits in the registry while the old container keeps serving.

Read the header on the wrong page. Some applications embed their own PHP-FPM pool; a legacy section of the site can answer with a different build than the main page. Check the URL that handles logins and payments.

The patch itself is one update. The work is making sure the update reached the process that answers requests — which is why the checklist orders these steps rather than listing them.

Related