How to Protect Against PHP2Shell: A PHP Update Guide

PHP2Shell is the name given to two critical flaws in PHP itself: CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution without authentication and score 9.2 on the CVSS v4.0 scale. This guide walks through what to do if you run your own server or hosting account, in order: find your version, update, apply a temporary measure, and check for signs of compromise. For a short news summary see our PHP2Shell news item.

What is PHP2Shell and what does it do?

Both flaws sit in the PHP processes that serve web requests, and an attacker only needs to send an HTTP request.

• CVE-2026-109618: when PHP runs out of memory while preparing request data, that data is left half-initialized, then treated as valid during cleanup, which can lead to code execution.
• CVE-2026-109619: PHP keeps request state after the memory behind it has been freed. When the same worker handles the next request, the stale state is read, which can cause memory disclosure and code execution.

The attacker runs code with the privileges of the web server user, and memory disclosure can expose passwords, tokens, API keys and certificates. On Apache mod_php the attack can fire before any application code runs, but every setup where PHP serves web requests is at risk, including PHP-FPM, php-cgi and LiteSpeed.

Because the flaw is in PHP and not in your application, updating WordPress plugins or your theme does not protect you on its own. The fix is to move PHP itself to a patched release.

Which version should you update to?

Do not wait for an official patch for PHP 8.1 and earlier. The PHP team published minimal patches for 7.4, 8.0 and 8.1, but they are meant for people who build from source, and running these versions on the public internet is not recommended. Where possible, move to the current 8.5.x branch and test your application.

1. Find your PHP version

The version you see on the command line can differ from the one serving your website, and several PHP versions on one server are common.

php -v
# PHP-FPM versions (Debian/Ubuntu)
ls /usr/sbin | grep php-fpm
# cPanel / CloudLinux
ls /opt/cpanel | grep ea-php
ls /opt/alt | grep php

On shared hosting, look at the PHP version selector in your control panel. If it shows 8.1 or older, switch to a current version your provider supports.

2. Update PHP

Commands depend on your distribution and where PHP was installed from. Take a backup first, then update and restart the services. Distribution packages can carry the fix without changing the version number, so besides the version also check the package changelog.

Debian and Ubuntu

sudo apt update
sudo apt install --only-upgrade 'php*'
sudo systemctl restart php8.3-fpm   # depending on your version
sudo systemctl restart apache2      # or nginx

AlmaLinux, Rocky Linux and RHEL

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd        # or nginx

If you use third-party repositories (for example Remi), make sure the update has reached the repository; volunteer-run repositories may not be ready on release day.

cPanel and CloudLinux

On these systems the provider publishes the PHP packages. In WHM use Software > EasyApache 4 and system updates for ea-php packages, and update the alt-php packages if you run CloudLinux. If your provider has not yet released patched packages, apply the temporary measures below.

Docker

docker pull php:8.3-fpm
docker compose build --pull
docker compose up -d

Confirm the image tag points to a fixed release with docker run --rm php:8.3-fpm php -v.

Verify the update

apt changelog php8.3-fpm | grep -i "CVE-2026-1096"
# RHEL family:
rpm -q --changelog php-fpm | grep -i "CVE-2026-1096"

If the output mentions CVE-2026-109618 and CVE-2026-109619, the package contains the fix. After verifying, make sure the PHP processes were restarted; old processes keep running the code from before the update.

3. Temporary measures if you cannot update right away

• Set session.upload_progress.enabled = Off in php.ini and restart PHP-FPM and the web server. It closes the known attack paths but is not a complete fix.
• According to one report, on PHP 8.5 setting fatal_error_backtraces = 0 also reduces risk; still, no setting replaces the update.
• Do not leave an old PHP you cannot update exposed to the internet. Put it behind a VPN or a web application firewall (WAF).
• Consider a maintenance page for critical sites. CISA advises taking systems that cannot be updated offline until they are patched.

4. Check whether you were attacked

No confirmed indicators of compromise have been published yet, but the behavior is clear. Look for:

• A PHP worker or web server (php-fpm, php-cgi, httpd, apache2) starting sh, bash, python, perl, curl, wget or nc.
• Reconnaissance commands such as whoami, id and uname -a run from the web server.
• New or modified PHP files in the web root (webshells), new cron jobs and new user accounts.

ps -eo user,ppid,pid,cmd --forest | grep -E "php-fpm|httpd|apache2" -A2
find /var/www -name "*.php" -mtime -3
crontab -l; ls -la /etc/cron.d

If you see anything suspicious, isolate the server from the network, keep the web server and PHP logs untouched, and rotate passwords, API keys and tokens. Memory disclosure means those values may have been exposed.

Checklist

1. List every PHP version on the server, including the one your control panel uses.
2. Move each to a fixed release; remove or upgrade unsupported versions.
3. Restart PHP-FPM, Apache and Nginx.
4. Confirm the CVE numbers in the package changelog.
5. Check the web root for new PHP files, cron jobs and users.
6. Test your site and application after the update.

Frequently asked questions

My site runs WordPress; does the flaw affect me?

The flaw is in PHP, not in WordPress. A WordPress site on a server whose PHP is not patched is at risk too; security firms have demonstrated exploitation against WordPress, Drupal and Joomla.

Is only mod_php affected?

No. The easiest exploitation was shown on mod_php, but setups where PHP serves web requests, such as PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, are also at risk.

Will the update break my site?

These are security releases, so staying within the same branch usually causes no compatibility problems. Still, take a backup and test your site after updating.

Where Fiberserver stands

PHP updates have been applied on Fiberserver hosting servers. Customers on our cPanel web hosting plans do not need to do anything beyond keeping a current PHP branch selected. On VDS and dedicated servers PHP is yours to manage, so apply the steps above. For the wider picture of server security see our VDS security guide, and open a support ticket if you get stuck.

Sources

• Huntress: PHP2Shell, leaked critical PHP vulnerabilities
• CISA: critical PHP vulnerabilities require immediate patching
• The Hacker News: PHP issues emergency patches for two critical flaws