🛡️ PHP2Shell Fix Guide — CVE-2026-109618 & CVE-2026-109619

Severity: CRITICAL (CVSS v4.0 9.2 for both) · Unauthenticated Remote Code Execution in the PHP runtime itself Your application code does not need to be vulnerable. If your PHP binary is, your site is exposed.

📌 Summary

On 21 October 2026, the PHP team released emergency security updates for two critical flaws, collectively named PHP2Shell. An attacker with no account can run code on a web server that serves PHP requests. Exploit attempts have been reported in the wild (no confirmed breaches at the time of writing). Only updating fully protects a server.

Advisories: GHSA-w8hw-w9fx-j79w (109618) · GHSA-6wmf-4rv5-p3rp (109619)

✅ Fixed Versions

Affected SAPIs include PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.

🚀 Step-by-Step Fix

1. Check your current version

php -v

⚠️ php -v shows the CLI binary. Your web server may use a different one. Confirm with a script served through the web server:

<?php echo PHP_VERSION; // temporary file, delete after checking

Find every PHP install on the box:

which -a php
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null

2. Update PHP

Ubuntu / Debian

sudo apt update
sudo apt install --only-upgrade php8.3 php8.3-fpm php8.3-cli php8.3-common
# replace 8.3 with your branch

Ubuntu with the Ondřej Surý PPA / Debian with sury repo

sudo apt update && sudo apt upgrade

RHEL / Rocky / Alma / CentOS Stream

sudo dnf module list php
sudo dnf update php\*

Docker

FROM php:8.3.36-fpm   # or 8.5.12 / 8.4.27 / 8.2.35

docker pull php:8.3.36-fpm
docker compose build --no-cache && docker compose up -d

cPanel / Plesk / CloudLinux: apply the vendor's PHP update from the control panel or yum/dnf, and check the vendor changelog for the CVE IDs.

💡 Distros and LTS vendors often backport the fix without changing the version number. Check the package changelog for the CVE IDs:

apt changelog php8.3-cli | grep -i "CVE-2026-10961"      # Debian/Ubuntu
rpm -q --changelog php-cli | grep -i "CVE-2026-10961"     # RHEL family

CyberPanel (OpenLiteSpeed / LSPHP)

CyberPanel runs PHP as lsphp packages (for example lsphp82, lsphp83, lsphp84), installed under /usr/local/lsws/. These come from the LiteSpeed repository, not the OS PHP packages, so apt upgrade php* does not update them.

# 1. List installed LSPHP versions
ls /usr/local/lsws | grep lsphp
/usr/local/lsws/lsphp83/bin/php -v        # check each version you use

# 2. Update LSPHP packages
# Ubuntu / Debian
sudo apt update
sudo apt install --only-upgrade 'lsphp8*'

# AlmaLinux / Rocky / CentOS
sudo dnf clean all
sudo dnf update 'lsphp*'

# 3. Confirm the fix landed
/usr/local/lsws/lsphp83/bin/php -v
apt changelog lsphp83 | grep -i "CVE-2026-10961"      # Debian/Ubuntu
rpm -q --changelog lsphp83 | grep -i "CVE-2026-10961"  # RHEL family

# 4. Restart OpenLiteSpeed so new LSPHP workers load
sudo systemctl restart lsws
# or
sudo /usr/local/lsws/bin/lswsctrl restart

CyberPanel notes:

• Per-site PHP version: Websites → List Websites → Manage → Change PHP. Move sites off EOL versions (8.1 and older) to 8.3 or 8.4.
• The LiteSpeed repo may take a little while to publish the patched builds. If --only-upgrade shows nothing new, run apt update / dnf clean all again later and check the LiteSpeed changelog for the CVE IDs.
• Update CyberPanel and its OS packages as well: sudo apt upgrade or sudo dnf update.
• If you also run Apache, Nginx, or PHP-FPM beside it, patch those PHP installs separately using the steps above.

3. Restart services (required)

The old interpreter stays in memory until restarted.

sudo systemctl restart php8.3-fpm     # adjust the service name
sudo systemctl restart nginx          # or apache2 / httpd

4. Verify the fix

php -v
curl -sI https://your-site.example | grep -i x-powered-by   # if exposed

Confirm the version served by the web server is >= 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or that the vendor package changelog lists both CVEs. Then delete any temporary version-check file.

🧯 Temporary Mitigation (only if you can't patch right now)

Mitigation is not a substitute for patching.

• Put the site behind a WAF (Cloudflare, ModSecurity, etc.) with the vendor's PHP2Shell rules enabled.
• Restrict access to non-public PHP apps by IP/VPN/basic auth.
• Reduce exposure of upload endpoints and large multipart requests until patched.
• Disable session upload progress tracking: session.upload_progress.enabled = Off (see below).
• Cap memory sensibly (memory_limit, FPM pm.max_children) to avoid uncontrolled OOM conditions.
• Rotate/recycle workers more often (pm.max_requests = 100) to reduce stale-state reuse.

Disable session.upload_progress.enabled

Set this directive to Off as hardening. It stops PHP from tracking upload progress in the session during multipart uploads.

⚠️ This is a hardening step, not a confirmed full mitigation for either CVE. Patching is still required. It may break upload progress bars that rely on $_SESSION["upload_progress_*"].

php.ini (generic)

session.upload_progress.enabled = Off

Where to put it

CyberPanel UI: PHP → Edit PHP Configs, choose the PHP version, find session.upload_progress.enabled under the advanced settings or paste it into the editor, save, then restart lsws.

Apply and verify

sudo systemctl restart php8.3-fpm        # PHP-FPM
sudo systemctl restart lsws              # CyberPanel / OpenLiteSpeed

php -i | grep -i upload_progress.enabled
# CyberPanel: use the matching binary
/usr/local/lsws/lsphp83/bin/php -i | grep -i upload_progress.enabled

Expected output: session.upload_progress.enabled => Off => Off. Also confirm through the web server with phpinfo() (temporary file, delete it after checking), since CLI and web configs can differ.

🔎 Post-Patch Checks (Assume Breach Hygiene)

Exploit attempts were observed, so check for signs of compromise:

# Recently modified PHP files in web roots
find /var/www -name "*.php" -mtime -7 -ls

# Suspicious files in upload/cache dirs
find /var/www -path "*/uploads/*" -name "*.php" -ls

# Unexpected processes owned by the web user
ps -u www-data -o pid,cmd

# Review web/PHP error logs for crashes, OOM, segfaults
grep -iE "segfault|out of memory|allowed memory" /var/log/nginx/*.log /var/log/php*/*.log

If anything looks suspicious: isolate the host, preserve logs, rotate secrets (DB creds, API keys, .env), and rebuild from a clean image.

⚠️ End-of-Life PHP (8.1 and older)

PHP 8.1 and older receive no upstream fix. Options, best first:

1. Upgrade to PHP 8.3 / 8.4 / 8.5.
2. Use a commercial LTS vendor that has shipped a backport (e.g., TuxCare, Zend, your distro).
3. Isolate the server behind a WAF and restrict access while migrating.

📋 Checklist

• [ ] Inventoried all PHP versions (CLI, FPM, containers, shared hosting)
• [ ] Updated to a fixed version or a verified vendor backport
• [ ] Updated CyberPanel lsphp* packages (if used) and restarted lsws
• [ ] Set session.upload_progress.enabled = Off and verified it
• [ ] Restarted PHP-FPM / Apache / web server
• [ ] Verified the version served by the web server
• [ ] Rebuilt and redeployed Docker images
• [ ] Reviewed logs and web roots for signs of exploitation
• [ ] Rotated secrets if compromise is suspected
• [ ] Planned migration off EOL PHP

📚 References

• The Hacker News: PHP Issues Emergency Patches for PHP2Shell
• Help Net Security: PHP2Shell patched
• Tenable FAQ
• CybelAngel: What we know about php2shell
• Official: php.net changelog and the php-src GitHub advisories

Last updated: 21 Oct 2026. Details may evolve, so check the official PHP advisories.