What happened: the October 2026 PHP security release

On October 20, 2026, the PHP project gave advance notice that a critical security release was coming the next day. On October 21 at 14:00 UTC the patched releases shipped: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. They fix two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Security researchers are calling the pair "PHP2Shell", and exploitation attempts have already been observed in the wild since the patches were released.

These are not ordinary bugs. Both flaws let an unauthenticated attacker run their own code on your server with the web worker's permissions, over plain HTTP, with no login and no interaction with your application. If your server runs PHP to serve web requests, treat it as affected until you have patched and verified.

This post explains both vulnerabilities in plain terms, shows you exactly which versions are fixed, and walks you through patching your server end to end, including the restart step most people forget.

The two vulnerabilities, in plain terms

CVE-2026-109618 (RCE via out-of-memory corruption). When PHP runs out of memory during a request, it uses longjmp() to bail out of the request immediately. If that bailout happens while request memory is only partly initialized, the shutdown code later reads invalid state and can be steered into executing attacker-controlled code as the web worker user. An attacker does not need to find a memory-hungry page on your site; the advisory lists ways to force the out-of-memory error during request parsing itself, such as multipart bodies with no usable Content-Length that slip past post_max_size, parts with unlimited headers, empty file fields that do not count toward max_file_uploads, and deeply nested field names.

CVE-2026-109619 (RCE via stale global state). A request that ends in a fatal error can leave global state behind that a later request reuses as if it were still valid memory. Because the memory has already been released, the attacker can influence what the new request finds there, again reaching code execution as the web worker user.

Both are fixed by updating PHP. There is no application-level substitute: PHP demonstrated that on Apache with mod_php the attack can trigger before any of your application code runs, so a CMS update, a security plugin, or changing admin passwords cannot replace the PHP fix.

Which versions are fixed

The October 21 releases are the first upstream versions containing both fixes:

  • PHP 8.5: fixed in 8.5.12 (8.5.11 and earlier are vulnerable)
  • PHP 8.4: fixed in 8.4.27 (8.4.26 and earlier are vulnerable)
  • PHP 8.3: fixed in 8.3.36 (8.3.35 and earlier are vulnerable)
  • PHP 8.2: fixed in 8.2.35 (8.2.34 and earlier are vulnerable)
  • PHP 8.1 and older: no official release. You need a vendor or distribution backport, or you must upgrade to a supported branch. cPanel has added patched packages to EasyApache 4 and backported the fix to its PHP 7.4, 8.0, and 8.1 packages.

Distribution vendors may backport the patches without matching these upstream version numbers, so if your package manager reports a different-looking version, ask the vendor to confirm the package's security status.

Who is affected

Every PHP SAPI that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The demonstrated risk is highest for Apache with mod_php, where remote code execution was confirmed for both flaws. On PHP-FPM, code execution was confirmed for CVE-2026-109619 through the session upload progress path, and the code path for CVE-2026-109618 is present. Running something other than mod_php is not a reason to skip the update.

Note there is also a related follow-up advisory from October 23, CVE-2026-115560, covering a lower-risk session handling issue. Patching to the October 21 releases is the priority; then review the session advisory for your setup.

Prerequisites

  • A Linux server (Ubuntu 22.04/24.04, Debian, RHEL/AlmaLinux/Rocky, or cPanel/WHM) running PHP 8.2 through 8.5 to serve web requests.
  • Root or sudo access on the server.
  • Know which SAPI you run: PHP-FPM (most common with Nginx/Apache event MPM) or Apache mod_php. Check with php -v on the CLI and, more importantly, through the web server, as shown in Step 1.
  • A backup or snapshot of the server before you change packages, so you can roll back if a package upgrade breaks a dependency.

Step 1: Check which PHP version your web server actually runs

The CLI version and the web version can differ. Check both, because the web-facing one is what attackers reach.

php -v

This prints the command-line PHP version. It tells you the branch, but the web SAPI may lag behind or be a different build.

echo '<?php phpinfo();' | sudo tee /var/www/html/phpver.php
curl -s http://localhost/phpver.php | grep -o 'PHP Version [0-9.]*' | head -1

This creates a temporary phpinfo() page and fetches it through the web server, showing the version that actually handles HTTP requests. Compare it against the fixed-version list above. Delete the file immediately afterwards, because phpinfo() pages leak configuration details.

sudo rm /var/www/html/phpver.php

Remove the temporary file as soon as you have the version number.

Step 2: Update PHP to the patched release

On Ubuntu or Debian with the Ondrej PHP PPA (the most common way to get current PHP on Ubuntu):

sudo apt update
sudo apt install --only-upgrade php8.4 php8.4-fpm php8.4-cli php8.4-common

apt update refreshes the package lists so the new patched builds are visible; --only-upgrade upgrades just the named PHP packages without touching unrelated software. Replace 8.4 with your branch (8.2, 8.3, or 8.5) and add any extra extensions you use, for example php8.4-mysql or php8.4-curl.

On RHEL, AlmaLinux, or Rocky Linux with the Remi repository:

sudo dnf upgrade 'php*'

This upgrades every installed PHP package to the latest available in the enabled repositories, which now include the patched builds.

On cPanel/WHM servers, update through EasyApache 4 in WHM (or the command line):

sudo /usr/local/cpanel/scripts/update-packages
sudo yum update ea-php82 ea-php83 ea-php84 ea-php85

cPanel ships the patched builds as ea-php82 8.2.35 and matching packages for the other branches, plus backported fixes for its 7.4, 8.0, and 8.1 packages.

If you run PHP 8.1 or older and your vendor offers no backport, plan the upgrade to PHP 8.4 now. PHP 8.4 is the current stable branch with active support, and it receives the October 21 fix in 8.4.27.

Step 3: Restart PHP-FPM and your web server

This is the step people skip, and it matters: running PHP workers keep the old vulnerable code in memory until they are restarted. The package upgrade alone does not fix a running server.

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2

The first command restarts the PHP-FPM pool manager so every worker loads the patched binary. The second restarts Apache, which covers both mod_php and the proxy-to-FPM path. On Nginx systems restart PHP-FPM and Nginx:

sudo systemctl restart php8.4-fpm
sudo systemctl restart nginx

Adjust the service name to your branch, for example php8.3-fpm or php8.2-fpm.

Step 4: Verify the fix through the web server

Do not rely on php -v on the command line; it can report a different build than the one handling requests. Verify through HTTP:

echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/phpver.php
curl -s http://localhost/phpver.php
sudo rm /var/www/html/phpver.php

The output must show a fixed release (8.5.12, 8.4.27, 8.3.36, or 8.2.35, or a vendor-backported equivalent). The file is removed immediately so it cannot be abused for information disclosure.

Verify it worked

  • curl -s http://localhost/phpver.php (before deleting it) returns a patched version number.
  • sudo systemctl status php8.4-fpm shows active (running) with a fresh start time after your upgrade.
  • Your site loads normally in a browser and PHP pages execute (test one dynamic page, not just static assets).
  • Check the web server error log for startup errors: sudo tail -30 /var/log/apache2/error.log or sudo tail -30 /var/log/nginx/error.log.

Common issues and fixes

1. apt says the newest PHP is already installed, but the version is still vulnerable. Your package source does not carry the patched build yet, or you are pinned to an old branch. Run sudo apt update first, then check apt policy php8.4 to see which versions the repository offers. If the repository genuinely has no fixed build, switch to the Ondrej PPA (ppa:ondrej/php) or your vendor's patched packages.

2. php -v shows the new version but the website still reports the old one. You upgraded the packages but did not restart the running workers. Restart PHP-FPM and the web server as in Step 3, then verify through HTTP again. Running processes keep the old code until they restart.

3. PHP-FPM fails to start after the upgrade. Usually a pool configuration references a module that changed. Check the exact error with sudo systemctl status php8.4-fpm and sudo journalctl -u php8.4-fpm -n 50. Common fix: a third-party extension (ionCube, SourceGuardian) built for the old minor version needs reinstalling from the vendor for the new build.

4. "Unable to load dynamic library" warnings in the log. An extension .so file is missing for the new PHP build. Install the matching package, for example sudo apt install php8.4-redis, or comment out the stale extension= line in the extension's ini file if you no longer need it.

5. cPanel EasyApache shows no update available. Run /usr/local/cpanel/scripts/update-packages first to refresh cPanel's package metadata, then re-check EasyApache 4. The backported packages for 7.4/8.0/8.1 appear under the same ea-phpXX names.

Temporary mitigations if you cannot patch immediately

PHP published temporary mitigations, but it calls them incomplete: patching is the only complete fix. If you must buy time, apply these together: set session.upload_progress.enabled=0, set fatal_error_backtraces=0 on PHP 8.5, run with memory_limit=-1 while enforcing memory limits at the host or container level, and block unneeded multipart uploads at your reverse proxy. Then schedule the real update as soon as possible, because researchers are already seeing "PHP2Shell" exploitation attempts in the wild.

Conclusion

The October 21, 2026 PHP security release fixes two critical remote code execution flaws with a CVSS score of 9.2. Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or a vendor-backported equivalent), restart PHP-FPM and your web server so the old code is actually gone, and verify the running version through HTTP. Servers on PHP 8.1 or older should treat this as the push to upgrade to a supported branch. If patching production PHP servers or planning the upgrade feels risky, XpertBees can handle the rollout, testing, and rollback plan for you.