How to Check and Patch PHP2Shell on Linux Servers (Ubuntu, Debian, RHEL, Docker)

Last updated: 22 October 2026. Applies to the PHP2Shell flaws CVE-2026-109618 and CVE-2026-109619. New to the issue? Start with our PHP2Shell explainer.

This guide is for anyone who runs their own Linux server or VPS with PHP: Ubuntu, Debian, RHEL/AlmaLinux/Rocky or Docker. It walks through four steps: find which PHP actually serves your sites, patch it, prove the patch is live, and check for signs of attack. If you are on shared hosting, read our shared-hosting checklist instead.

Target versions: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or a distribution package that includes the backported fix.

Step 1: Find the PHP that serves web traffic

The php command on your shell is the CLI build. Your website may run a different version through PHP-FPM, Apache mod_php or LiteSpeed. Check all of them:

# CLI version and which php.ini it loads
php -v
php --ini | head -3

# Running PHP services (FPM pools, LiteSpeed, Apache)
systemctl list-units --type=service | grep -Ei 'php|httpd|apache|lsws'

# What the web server reports to visitors (if expose_php is on)
curl -sI https://your-domain.com/ | grep -i '^x-powered-by'

Also remember containers, control panels (cPanel/Plesk ship their own PHP builds) and appliances that bundle PHP. Each one needs its own update.

Step 2: Patch

Ubuntu

Canonical has published fixes for every supported release. 20.04 and older need Ubuntu Pro (ESM), which is free for up to 5 machines. Because of backporting, the version number may barely change:

# See installed PHP packages and their versions
dpkg -l | grep -E '^ii +php[0-9.]+-(common|cli|fpm)'

# Update only the installed PHP packages ...
sudo apt update && sudo apt install --only-upgrade '?installed ?name(^php)'

# ... or apply all pending updates (recommended)
sudo apt update && sudo apt upgrade

Watch out: on Ubuntu 24.04, a patched server still prints PHP 8.3.6 in php -v. A simple “is the version ≥ 8.3.36?” check will wrongly say you are vulnerable. Compare the full package version (8.3.6-0ubuntu0.24.04.13 or later) instead.

Debian

sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^php'
sudo apt upgrade
dpkg -l | grep -E '^ii +php[0-9.]+-common'   # compare with the Debian security tracker

If you use the Ondřej Surý (deb.sury.org) repository, apply its updates the same way and check that the upstream version is 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later.

RHEL, AlmaLinux, Rocky, Fedora

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'
rpm -q php-common php-fpm    # compare with your vendor's advisory (e.g. RHSA)

If you install PHP from the Remi repository, check its status before you rely on it: Remi had no updated packages on release day. Until it does, the advice from PHP and security researchers is to switch to distribution packages or build from source.

Docker and containers

Updating the host does nothing for PHP inside an image. Rebuild every image from a patched base and redeploy it:

# Check the PHP version inside a running container
docker exec <container> php -v

# Rebuild with a fresh base image (e.g. FROM php:8.3-fpm), then redeploy
docker build --pull --no-cache -t myapp:patched .

Pin to a fixed tag such as php:8.3.36-fpm or later, so a cached old layer can’t slip back in.

Old PHP (7.4, 8.0, 8.1 and earlier)

PHP will not release new versions for these branches. Your options: a distribution or LTS vendor backport (Ubuntu ESM, RHEL, commercial LTS), PHP’s minimal source backports for 7.4–8.1, or upgrading to PHP 8.3+. If none of these is possible soon, take the site off the public internet or put it behind a VPN or WAF.

Step 3: Restart and verify

Updated packages do nothing until the running processes restart. Restart every PHP service, then check again:

# Examples: use the service names from Step 1
sudo systemctl restart php8.3-fpm       # Ubuntu/Debian FPM
sudo systemctl restart php-fpm          # RHEL family FPM
sudo systemctl restart apache2          # Apache with mod_php (httpd on RHEL)
sudo systemctl restart lsws             # LiteSpeed / OpenLiteSpeed

# Confirm the web-facing version
curl -sI https://your-domain.com/ | grep -i '^x-powered-by'

For the most reliable check, place a temporary file in the web root containing <?php echo PHP_VERSION, " ", PHP_SAPI;, open it in the browser, then delete it immediately. Or rescan with your vulnerability scanner: Tenable, Qualys and others have published PHP2Shell checks.

Temporary mitigations (only if you cannot patch today)

These come from PHP’s own guidance. They reduce known attack paths but do not fix the bug. Set them at the server or pool level. ini_set() and .user.ini are not enough. Restart workers afterwards.

; PHP-FPM pool file, e.g. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 only:
php_admin_value[fatal_error_backtraces] = 0

# Apache mod_php (inside the VirtualHost)
php_admin_flag session.upload_progress.enabled off

PHP also lists measures against the out-of-memory bug: enforcing memory_limit=-1 administratively, tightening post_max_size and request-size limits at the web server, and blocking multipart requests where the app doesn’t need them. Removing the memory limit raises the risk of resource exhaustion, so treat it strictly as temporary, and undo these changes once you are patched.

Step 4: Check for signs of compromise

Exploitation attempts were seen from 17 October 2026, so check activity from that date even after patching:

# Child processes of PHP / web server workers (shells, curl, wget, nc ... are red flags)
for p in $(pgrep -f 'php-fpm|php-cgi|lsphp|apache2|httpd'); do
  ps --ppid "$p" -o user=,pid=,ppid=,etime=,cmd=
done | grep -vE 'php-fpm|php-cgi|lsphp|apache2|httpd'

# PHP files created or changed since 17 Oct in the web root
sudo find /var/www -name '*.php' -newermt '2026-10-17' -ls

# Common webshell / reverse-shell strings
sudo grep -rlE 'fsockopen|/dev/tcp/|mkfifo|base64_decode\(\$_(POST|GET|REQUEST)' /var/www --include='*.php'

# Cron jobs for the web user and new login accounts
sudo crontab -u www-data -l
awk -F: '$3 >= 1000 {print $1, $3, $7}' /etc/passwd

Adjust /var/www and www-data to your setup (for example apache or nginx on RHEL). Legitimate plugins sometimes contain these strings, so review matches rather than deleting them. If you find something suspicious: isolate the server, preserve the web server and PHP logs before changing anything, rotate every secret the app uses (database, API keys, salts), and rebuild from a known-good backup.

Quick checklist

• ☐ Every PHP install found (CLI, FPM, Apache, LiteSpeed, containers, panels)
• ☐ Updated to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or the patched distro package
• ☐ All PHP workers restarted and the web-facing version confirmed
• ☐ Temporary mitigations removed after patching
• ☐ Logs, files, cron and accounts reviewed from 17 Oct onwards
• ☐ End-of-life PHP upgraded, backported or taken offline

For broader hardening, use our free Linux server hardening checklist. If you want an expert to patch and verify your servers, see our Linux server hardening & audit service.

Sources

• Ubuntu: php2shell vulnerability fixes available
• Qualys: PHP2Shell remediation and mitigations
• Tenable: php2shell FAQ
• Huntress: detection guidance
• Help Net Security: PHP2Shell patched