DEV Community

Sospeter Mong'are
Sospeter Mong'are

Posted on

PHP2Shell: Two Critical PHP Remote Code Execution Flaws (CVE-2026-109618 and CVE-2026-109619) and How to Patch Them

#php #linux #ubuntu #beginners

Introduction

On October 21, 2026, the PHP project shipped emergency security releases for two critical vulnerabilities nicknamed PHP2Shell. They let an unauthenticated attacker run code on a server through an ordinary HTTP request, and they live in the PHP engine itself, so a perfectly written application can still be exposed. Because PHP powers WordPress, Magento, Drupal, countless control panels and most shared hosting, the reach is enormous.

The confusing part is the patching. Ubuntu and other distributions fix PHP without changing the version number, so a server reporting an old version such as 8.3.6 might be vulnerable or might be fully patched. Shared hosting customers and WordPress owners also can't simply "run an update". This article explains what the flaws are, which versions are affected, which are fixed, and exactly what to do whether you run your own Ubuntu server, a cPanel server, shared hosting, or a WordPress site.

What happened

On October 21, 2026, the PHP team released emergency security updates for PHP2Shell, two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that could let attackers execute code remotely on web servers without logging in. The PHP security team rated each 9.2 on CVSS v4.0, and security firm watchTowr rated it a full 10.0.

The flaws are in the PHP engine itself, not in any one application. Magento, Shopware and WooCommerce stores are exposed even when their own code is clean.

The two vulnerabilities

  • CVE-2026-109618, "RCE via OOM corruption." Out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat the invalid data as valid. JFrog's analysis says it can also cause Heartbleed-style memory disclosure.
  • CVE-2026-109619, "RCE via stale global state." A PHP worker can reuse stale state from a previous request.

Researchers describe the internals differently. Several tie both bugs to PHP's session upload-progress feature, which is why disabling that feature is the main stopgap (see below).

Affected versions

Versions as early as PHP 5.4 through PHP 8 are affected, so the vulnerable code is about 14 years old. Every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Fixed versions

Branch Vulnerable Fixed
8.5 before 8.5.12 8.5.12
8.4 before 8.4.27 8.4.27
8.3 before 8.3.36 8.3.36
8.2 before 8.2.35 8.2.35
8.1 and earlier End of life No standard release

If you run an end-of-life branch, moving to a supported branch is the real fix. PHP 8.2 also reaches end of life on 31 December 2026, so don't treat 8.2 as a long-term home.

Is it being exploited?

Reports differ. Amazon Threat Intelligence recorded an exploitation attempt on October 17, four days before public disclosure, and Cloudflare has also reported attack traffic, including attempts to evade its protections. However, as of October 21, PHP had not reported in-the-wild exploitation, and CISA had not added either CVE to its catalog. Treat it as actively targeted either way.

Do you really need to upgrade?

Yes, you need to upgrade, but not to 8.3.36 if you installed PHP from Ubuntu's own repositories. Staying on the Ubuntu package is fine and is the recommended route. Ubuntu backports fixes without changing the version number, so you need the right build of 8.3.6, not a new PHP version.

For Ubuntu 24.04 (Noble), the fixed package is 8.3.6-0ubuntu0.24.04.13. That build is fixed even though it says 8.3.6. Anything older, such as .9, .10 or .11, is still vulnerable, even though php -v looks identical. Ubuntu's advisories are USN-8948-1 and USN-8948-2.

The rule of thumb: the version string alone doesn't tell you whether you're patched. If PHP came from your distribution, check the package build and changelog. If it came from upstream or a third-party repository (such as Ondřej Surý's PPA), you need 8.3.36 or later.

How to patch your own server

Ubuntu and Debian (distribution packages) 

# What's installed?
dpkg -l | grep -E '^ii\s+php8.3'

# Upgrade
sudo apt update
sudo apt upgrade        # or: sudo apt install --only-upgrade 'php8.3*' 'libapache2-mod-php8.3'

# Confirm: on Ubuntu 24.04 the version should end in .13 or higher
dpkg -l php8.3-cli | tail -1
apt changelog php8.3-cli | grep -i CVE-2026

# Restart so running workers pick up the fix
sudo systemctl restart php8.3-fpm     # PHP-FPM
sudo systemctl restart apache2        # mod_php
Enter fullscreen mode Exit fullscreen mode

Note the command is apt changelog, not apt-changelog. Restarting is essential: updated packages do not affect already-running workers. If you added a third-party PPA, check which repository supplies the package with apt-cache policy php8.3-cli and make sure you reach 8.3.36 or later.

On Debian, check the Debian security tracker for the fixed package version of your release, as I could not verify it at the time of writing.

RHEL, Rocky and AlmaLinux 

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm     # or httpd, depending on your setup
rpm -q --changelog php-fpm | grep CVE-2026
Enter fullscreen mode Exit fullscreen mode

cPanel/WHM servers (root access)

cPanel ships its own PHP builds (ea-php), separate from the operating system's PHP. Fixed builds were backported at the same version for older branches: ea-php74 7.4.33-19, ea-php80 8.0.30-12 and ea-php81 8.1.34-5. Update with /scripts/upcp, or dnf upgrade 'ea-php*' (yum on EL7), then restart Apache or PHP-FPM. The fixed build numbers for the newer ea-php branches (8.2 and up) were not confirmed, so check cPanel's EasyApache 4 changelog. If you resell hosting, check each account's PHP version in MultiPHP Manager, because accounts pinned to different versions can be patched at different times.

Shared hosting (no root access)

You can't patch PHP yourself on shared hosting. Your host has to. Here is what you can do:

  1. Check your PHP version in cPanel under MultiPHP Manager, or put <?php phpinfo(); in a temporary file and delete it right after. Remember a backported build can still show an old version number.
  2. Ask your host in writing whether PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is patched, and when.
  3. Apply the stopgap. In cPanel's MultiPHP INI Editor, or in a .user.ini file in your site root, set session.upload_progress.enabled = Off. Some hosts lock these settings, so confirm it took effect. Updating is still the only complete fix.
  4. Don't rely on a lower-numbered PHP version as a workaround. Everything from PHP 5.4 up is affected.

WordPress sites

The vulnerability is in PHP, not in WordPress, so updating WordPress core, themes or plugins does not fix it. Because the flaws are in the PHP engine, sites are exposed even when their own code is clean. Do this:

  • Get PHP patched (by your host or on your server), then restart PHP.
  • Disable session.upload_progress in the meantime.
  • Put a WAF in front of the site if you can. Cloudflare has reported attack traffic targeting these flaws.
  • Look for signs of compromise: unfamiliar PHP files in wp-content/uploads, new admin users, modified .htaccess, and unusual file modification dates. Check logs back to at least October 17, since exploitation was recorded four days before disclosure.
  • Take a backup before and after patching.

If you can't patch immediately

Updating is the only complete fix. As a stopgap, disable the session upload-progress feature:

session.upload_progress.enabled = Off
Enter fullscreen mode Exit fullscreen mode

Put it in your php.ini or a conf.d file, then restart PHP. Also consider WAF rules and request-size limits at your proxy. After patching, review logs for unusual multipart POST requests and unexpected PHP worker crashes or memory errors, going back to at least October 17.

Common mistakes to avoid

  • Assuming php -v showing 8.3.6 means you are vulnerable (on Ubuntu it may be patched) or that it means you are safe (it may not be). Check the package build.
  • Upgrading the package but not restarting PHP-FPM or Apache.
  • Updating WordPress and assuming that closes the hole.
  • Using apt-changelog, which is not a standard command. Use apt changelog <package>.
  • Staying on an end-of-life PHP branch with no fix available.

Conclusion

PHP2Shell is serious because it needs no login, sits in PHP itself, and has been probed in the wild since before disclosure. The good news is that fixes are out for every supported branch: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 upstream, and backported builds from Ubuntu (8.3.6-0ubuntu0.24.04.13 on 24.04) and cPanel. If you manage your own server, update, restart PHP and verify the package changelog. If you are on shared hosting, press your provider for a patch date and apply the session.upload_progress stopgap. If you run WordPress, remember the fix lives at the PHP layer, so check for compromise as well as patching. Either way, act now rather than waiting on a version number to tell you whether you are safe.

Sources

Top comments (0)