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

Last updated: 4 November 2026 (CISA listed both CVEs as known exploited on 26 October; CVE-2026-115560 still unfixed). 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.

Affected by this? Emergency exposure check, ₹2,999, 48 hours. Send us up to 5 hosts, sites or product versions. Within 48 hours you get a written verdict for each one, what to patch first and how to verify the fix. Book the check or ask a question first.

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

Fixed packages reported so far: Debian 13 (trixie) php8.4 8.4.27-1~deb13u1 and Debian 12 (bookworm, LTS) php8.2 8.2.35-1~deb12u1. Debian 11 had no free fix when we last checked. Confirm the version for your release on 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)

Red Hat has published fixes for its supported streams, for example RHSA-2026:87070 and 87071 (RHEL 10), RHSA-2026:87072 and 87079 (RHEL 9 php:8.2 and php:8.3) and RHSA-2026:87073 and 87080 (RHEL 8 php:8.2 and php:7.4). Retired streams such as RHEL 9 php:8.1 and RHEL 8 php:8.0 get no Red Hat fix. AlmaLinux patched every stream, including retired ones, and Rocky rebuilds Red Hat’s packages. Patched builds don’t always show in php -v, so check with rpm -q against the advisory.

If you install PHP from the Remi repository, update it now: Remi ships 8.4.27 and 8.5.12, plus backported builds for the end-of-life 8.0 and 8.1 branches. Its PHP 7.2 and 7.3 builds for RHEL 8 have no fix.

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. Undo the memory and request-size changes once you are patched.

Keep upload progress off even after patching. On 23 October PHP announced a related issue, CVE-2026-115560, that the 21 October releases do not fix. It only affects apps that switch session.serialize_handler at runtime, and no exploitation is known. PHP’s advice is to keep session.upload_progress.enabled off until its next regular release. As of 4 November there has been no regular release since 21 October, so the setting is still needed.

Step 4: Check for signs of compromise

Exploitation attempts were seen from 17 October 2026, successful exploits were confirmed on honeypots on 24 October, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October. Check activity from 17 October 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
• ☐ Memory and request-size mitigations removed after patching (upload progress stays off until PHP’s next release)
• ☐ 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.

Related guides

• How to Audit Unix and Linux Systems: Commands and Checklist
• Linux Special Permissions (SUID, SGID, Sticky Bit) and ACLs Explained
• How to Install Nginx on CentOS Stream, Rocky Linux and AlmaLinux
• Linux Fundamentals and Basic Commands for Beginners

Sources

• Ubuntu: php2shell vulnerability fixes available
• Qualys: PHP2Shell remediation and mitigations
• Tenable: php2shell FAQ
• Huntress: detection guidance
• Help Net Security: PHP2Shell patched
• Red Hat bulletin RHSB-2026-013 (php2shell)
• AlmaLinux: patched PHP packages released
• The Hacker News: PHP warns of CVE-2026-115560