PHP2Shell fix: patch PHP, restart workers, verify it ran

To fix PHP2Shell (CVE-2026-109618 and CVE-2026-109619), update the PHP packages on every server that serves web requests, then restart every PHP-FPM, Apache, LiteSpeed or CGI process that uses them. Fixed upstream releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Vendor backports keep older numbers. The job is done only when the running service started after the update.

The full facts are in the background on how PHP2Shell works. If a host runs PHP for you, start with questions to put to your host. The rest of this page is for people who run the server, or who want to check what their host did. The wider picture is in the October 2026 tracker, and the other PHP2Shell guides each take one question in depth.

Why is "package updated" not the same as "fixed"?

Two separate things must be true. First, the package on disk contains the fix. Second, every process serving requests was started from that package. A long-lived PHP-FPM master or Apache worker keeps running the code it loaded at start, whatever is on disk afterwards. Canonical says the same in its notice: applications that use PHP usually need a restart or a reboot after the upgrade.

The Debian tracker and every vendor table below only record the first thing. The second is yours to prove, and the verification section shows how.

How do I patch each channel?

Debian

Debian's own packages are fixed per release. At our check on 23 October 2026 the Debian tracker listed bookworm PHP 8.2 fixed at 8.2.35-1~deb12u1 and trixie PHP 8.4 fixed at 8.4.27-1~deb13u1. It still listed PHP 8.2 in sid as unfixed. Packages from a third-party repository are tracked by that repository, not here.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart php8.4-fpm

Replace the unit name with the one for your branch, and use apache2 instead if you run mod_php. Package fixed: the tracker. Worker restarted: only the service start time can tell you.

Ubuntu

Canonical lists a fixed package for every release, including ESM releases. It does not match upstream numbers.

sudo apt update && sudo apt install --only-upgrade '?name(^php[0-9.]+$)'
sudo systemctl restart apache2

Restart php8.3-fpm or your equivalent for FPM setups. Unattended upgrades install the package on their own, and Canonical says the application still needs a restart or reboot afterwards.

RHEL, AlmaLinux and Rocky

Red Hat's bulletin RHSB-2026-013 covers RHEL 8, 9 and 10, and RHEL 7 for CVE-2026-109619 only. At our check it said some updates were available and gave no package versions. Read the CVE page for your stream before you rely on a version. Containers built on RHEL or UBI images must be rebuilt once the base image updates.

AlmaLinux published exact packages per module stream on 21 October and says to verify with rpm -q php-common, not php -v.

sudo dnf clean metadata && sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

Use httpd instead for mod_php. Rocky Linux: we found no dated Rocky advisory at our check. Read Rocky's errata for your stream and the installed RPM changelog. Do not copy a status from Alma or Red Hat.

Alpine

We could not read an Alpine advisory or package record for these CVEs at our check; the Alpine security tracker page for CVE-2026-109618 returned 404. Treat the status as unknown. Check the package revision of your installed php* package in the Alpine package index for your branch, then upgrade it. Alpine package names carry the branch, such as php84-fpm.

apk update && apk upgrade

On a full Alpine host restart the OpenRC service for your branch. In an Alpine-based container there is no init system to restart, so the container must be replaced. That is the Docker step below.

cPanel EasyApache and CloudLinux alt-php

CloudLinux says fixed ea-php packages for ea-php52 to ea-php85 were released on 21 October, with builds carrying php.net numbers for ea-php82 to ea-php85 added later. It says alt-php is fixed for 5.2 to 8.5 on CloudLinux 7, 8 and 9, with CloudLinux 6 not confirmed at its 23 October update. These are vendor statements, and installing the packages is the server owner's job.

dnf clean all && dnf upgrade "ea-php*"
dnf clean all && dnf upgrade "alt-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Use yum on CloudLinux 7. CloudLinux says the backported packages keep lower numbers, so check the changelog for both CVE ids with rpm -q --changelog. Package fixed: the changelog. Worker restarted: the two restart scripts, or the LiteSpeed restart if that is your handler. The panel screens are walked through in updating PHP from cPanel.

Docker images

Docker's official php image listed 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at our check, on Debian trixie and bookworm and on Alpine 3.24 and 3.23. A running container never changes its own PHP. Which Docker images are patched has the tag list. You must rebuild from the new base and replace the container.

docker build --pull --no-cache -t myapp:fixed .
docker compose up -d --force-recreate

Package fixed: your image contains the new PHP. Worker restarted: the container is a new one. Check both, and check every image that bundles PHP, including queue workers and cron containers.

Heroku and buildpack platforms

Heroku's changelog of 21 October lists runtime builds 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus a rebuilt 8.1.34 on Heroku-22 with the backported fix, which Heroku calls a minimal mitigation rather than a supported release. Its instruction is to redeploy. Heroku's PHP support page says a rebuild with an unchanged composer.lock reinstalls the same PHP version, so read the build log for the resolved runtime.

git commit --allow-empty -m "Rebuild for PHP fix"
git push heroku main

Package fixed: the build log shows a fixed runtime. Worker restarted: dynos run the new release after the deploy. For other buildpack platforms, ask the platform whether the buildpack contains both fixes and whether a redeploy is required.

How do I verify the running service?

Do these on the server. None of them needs anything beyond reading state.

• Web, not CLI. php -v reports the command line binary. The web service can be another binary entirely. Ask the FPM binary itself (php-fpm8.4 -v or your equivalent), or load a temporary page that calls phpinfo() and read the version, Server API and build date. Delete the page the same minute.
• Response header. If X-Powered-By is on, it shows the version the web service reports. It shows the branch string, so a backport still looks old, and many sites switch it off.
• Service start time. systemctl status for the FPM or Apache unit shows when it started. That time must be later than the package install time (rpm -q --last php-fpm or the dpkg log).
• Stale binary. A process whose binary was replaced on disk after it started shows (deleted) on its /proc/<pid>/exe link. That process predates the fix.
• Every pool and virtual host. Servers with several PHP versions need each checked. A control panel that shows "8.3" shows the branch, not the build. On Plesk, reading the real PHP version takes a few steps.

Container hosts compare the running container's image digest with the image they built.

Am I affected? A three-state self-test

What if I cannot upgrade because my PHP is end of life?

The PHP project's notice says 8.1 and older no longer receive project updates. It published minimal source backports for 7.4, 8.0 and 8.1, and says some distributions and LTS vendors ship backports too. On php.net's supported versions page, 8.2 gets security fixes only until 31 December 2026, so 8.4 or 8.5 is the better target.

The options for 8.1 and older are covered on their own page. In order of preference:

1. A vendor backport that names both CVEs. Ubuntu ESM, AlmaLinux's retired streams, CloudLinux ea-php and alt-php, and Heroku's 8.1.34 all have one. AlmaLinux warns that retired streams may get no further fixes. Read the changelog.
2. A move to a supported branch. Test the application on 8.4 or 8.5 in staging first. Plugins and themes are usually what break.
3. Interim settings from the PHP notice. They apply to CVE-2026-109618: set memory_limit=-1 at server level, cap post_max_size, and limit multipart parts at the web server or proxy. For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini or the pool, never with ini_set(), and restart every worker. PHP's 23 October update about CVE-2026-115560 recommends the same setting. PHP calls updating the only complete solution.
4. Reduce who can reach the origin. Restrict direct access to the origin so traffic only arrives through your proxy or WAF, and take the site offline if nothing else is possible.

Did anything get in before the patch?

Patching removes the hole, not anything planted before it. The signs of an exploited site are listed on their own page. If PHP was unpatched and reachable from 17 October, check upload directories for unexpected PHP files, cron entries you did not create, new administrator accounts, and outbound connections from the web server. AWS reported honeypot attempts from 17 October (AWS, vendor-claimed). If you want an outside view of what your site shows, the free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup, and the checklist in this week's security list and the 10-minute response cover the rest.