How to check and fix PHP2Shell

Updated 23 October 2026. Covers CVE-2026-109618 and CVE-2026-109619.

On 21 October 2026, PHP released fixes for two critical flaws in PHP itself. Both let an attacker run their own code on your web server without logging in. Exploit attempts were seen from 17 October, before the public announcement.

The short version: update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or later), then restart every PHP process. No configuration change fully protects you. Your website's own code doesn't need to change.

1. Find out which PHP you run

On the server's command line:

php -v

A server can have several PHP versions installed, and the one your website uses can differ from the command-line one. Our read-only check script lists all of them, checks whether running PHP-FPM services need a restart, and tells you each version's status:

curl -fsSLO https://patchferry.pages.dev/check/patchferry-check.sh
less patchferry-check.sh      # read it first: it only reads, it changes nothing
sudo bash patchferry-check.sh

The scripts are open source, so you can read every line or report a problem on GitHub.

To see the version your website runs, upload patchferry-check.php to your site, open it once in a browser, and delete it. It stops working by itself after one hour.

On shared hosting, look for "PHP version" or "Select PHP version" in your control panel.

2. Compare with the fixed versions

Your version	What to do
8.2, 8.3, 8.4, 8.5	Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later, then restart PHP.
7.4, 8.0, 8.1	No official release. PHP published source patches, and some OS vendors have backported them. Check your vendor's advisory, then plan an upgrade to 8.3 or 8.4.
7.3 and older	No fix exists. Upgrade, or take internet-facing sites offline until you can.

A note on vendor builds: Ubuntu, Debian, Red Hat and CloudLinux often backport security fixes without changing the version number. A version like 8.3.6-0ubuntu0.24.04.x may already be fixed. Check your vendor's security notice, or just install all pending updates.

3. Update and restart

Take a backup or snapshot first if you can. Then follow the section for your setup.

Ubuntu or Debian

sudo apt update
sudo apt install --only-upgrade $(dpkg -l | awk '/^ii +php/{print $2}')
# or simply upgrade everything: sudo apt upgrade
# restart PHP-FPM for each version you run, for example:
sudo systemctl restart php8.3-fpm
# if you use Apache with mod_php:
sudo systemctl restart apache2

This works for both the official Ubuntu/Debian packages and the Ondřej Surý repository. Some Ubuntu packages were still being built on the day of release; if you don't see an update yet, check again later.

Red Hat, AlmaLinux, Rocky (including the Remi repository)

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd   # if Apache runs PHP

cPanel / WHM (EasyApache 4)

sudo dnf upgrade 'ea-php*'      # use yum on older systems
sudo /scripts/restartsrv_apache_php_fpm
sudo /scripts/restartsrv_httpd

If you use CloudLinux alt-php, also update alt-php*.

Plesk

Go to Tools & Settings, then Updates, and install the PHP updates. Then restart the PHP-FPM services from Tools & Settings, Services Management.

Docker

Rebuild your image on a patched base and redeploy. Pinning the exact version makes the change visible in code review:

# Dockerfile
FROM php:8.4.27-fpm

docker build --pull --no-cache -t your-app .

If you use a floating tag such as php:8.4-fpm, --pull fetches the patched image. A running container doesn't update until you redeploy it.

Shared hosting or managed platforms

Most large hosts patched on release day. Confirm with the web check above, and if the version is still old, ask your host's support directly. On Laravel Cloud, apps were patched automatically; Forge servers need the update from step 3.

4. Check it worked

Run php -v again and confirm the fixed version.
Run the check script again. It should show no "RESTART NEEDED" lines.
Open the web check file once more to confirm your website's version, then delete it.

If you can't update today

Setting session.upload_progress.enabled = Off in php.ini blocks some known attack paths, but not all. Use it only as a stopgap.
If your site is behind Cloudflare, Cloudflare has deployed firewall rules for the known exploits. On paid plans, check that the managed rules are switched on.
For servers that can't be updated soon, consider limiting access to known IP addresses or taking them offline, as several government agencies did.
Exploit attempts started on 17 October, so if you investigate a server, check the logs from that date onwards.

Stuck on an old PHP version?

Moving from PHP 7 to PHP 8 usually breaks something: old plugins, removed functions, outdated libraries. That's the work we do, tested on a copy before your live site changes, at a fixed price. Get a free assessment or message us on WhatsApp.

Official sources

php.net: release announcements and changelogs
CISA alert, 21 October 2026
Datadog Security Labs analysis