PHP2Shell: Critical PHP Vulnerabilities (CVE-2026-109618/109619) and How to Fix Them

On 21 October 2026 the PHP project released emergency updates for two critical PHP vulnerabilities that can let an attacker run their own code on a web server without logging in. Security researchers have nicknamed the pair “PHP2Shell”. Details leaked ahead of the planned disclosure, and public exploit code appeared online within hours, so this is one to fix today, not next week.

If your website, shop or web app runs on PHP (WordPress, WooCommerce, Laravel, Magento, Drupal, Joomla and most custom PHP apps), these PHP vulnerabilities affect you.

What happened

The PHP security team published two vulnerabilities, each rated 9.2 out of 10 (CVSS v4.0):

• CVE-2026-109618, remote code execution via out-of-memory corruption. When PHP runs out of memory at the wrong moment, it can leave internal request data half-initialised, and cleanup code then treats that broken data as valid.
• CVE-2026-109619, remote code execution via stale global state. Internal state from one request can survive after its memory is freed, and a later request handled by the same worker may use it.

According to the PHP team, every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for Apache with mod_php, where the attack can trigger before any of your application code runs. Your WordPress plugins or Laravel middleware can’t stop it.

European and UK cyber agencies (CERT-EU and the NCSC) both issued alerts, advising organisations that can’t patch quickly to consider taking public-facing systems offline until they do.

Which versions fix the PHP vulnerabilities

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35 (8.2 reaches end of life on 31 December 2026, so plan your upgrade)

PHP 8.1 and older no longer receive official releases. The PHP team published minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions ship their own patched packages, but the safest move is upgrading to a supported version. Old runtimes are a classic form of technical debt, and this is exactly when it gets expensive.

Step 1: Find every PHP installation

Most incidents happen on the server everyone forgot: an old staging site, a test subdomain, a Docker image nobody rebuilt. On each Linux server, run:

php -v
ls /etc/php/
systemctl list-units | grep -Ei 'php|apache|nginx'

Note the version and how PHP is served: a phpX.Y-fpm service means PHP-FPM, while Apache with no FPM service usually means mod_php.

Step 2: Update

Ubuntu / Debian

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.4*'      # use your version
sudo systemctl restart php8.4-fpm              # or: sudo systemctl restart apache2

Important: if you use your distribution’s own PHP packages (for example PHP 8.3 on Ubuntu 24.04), the version number often stays the same after patching, because distributions backport fixes. php -v may still say 8.3.6 even though you’re safe. Check the package changelog instead:

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20

Look for CVE-2026-109618 and CVE-2026-109619 in the latest entry.

If you use a third-party repository (such as the popular Ondřej Surý PPA), the version number does change, so php -v should show one of the fixed versions above. Builds for different distributions can land a few hours apart, so if no update is offered yet, apply the temporary measures below and check again later.

Docker

Pull the patched official image tag, rebuild your images and redeploy. Restarting an old container does not patch it.

Shared hosting and control panels

In your hosting panel (cPanel, Plesk, hPanel and so on), switch the site to the newest PHP version available and confirm with your host that it includes the October 21 fixes. If your site is still on PHP 7.x or 8.0/8.1, now is the time to move.

Step 3: Restart, then verify

A patch only takes effect once PHP is reloaded. Restart PHP-FPM or Apache, then confirm the service started after the update was installed:

systemctl show php8.4-fpm -p ActiveEnterTimestamp   # or apache2

Can’t update right now? Reduce the risk

The PHP team is clear that only updating is a complete fix. The following settings close known attack paths but do not make a server safe:

• Disable session upload progress in php.ini or your FPM pool (not with ini_set() or .user.ini), then restart every worker:
  session.upload_progress.enabled = 0
  Most modern apps, including Laravel and WordPress, don’t need this feature, so it’s usually safe to leave off permanently.
• Keep request sizes small. Set a low post_max_size (8M if you don’t need uploads, 32M if you do) and keep upload_max_filesize below it.
• On PHP 8.5, also set fatal_error_backtraces = 0.
• The PHP team also describes a memory_limit-based mitigation for the first CVE. Read their advisory before applying it, because it changes how memory errors behave.
• If a public-facing site can’t be patched or mitigated, consider taking it offline until it can.

Step 4: Check whether you were already hit

Because exploit code was public before many servers were patched, it’s worth a quick look for anything unexpected:

sudo find /var/www -name '*.php' -newermt '2026-10-18' \
  -not -path '*/vendor/*' -not -path '*/storage/framework/*'

Any PHP file you didn’t deploy yourself, especially in upload folders, is a red flag. Also review access logs for unusual POST requests and check for unknown admin users in your CMS. If you do find something, a clean, tested backup is what lets you recover quickly.

Quick checklist

• List every server, container and hosting account that runs PHP
• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched distribution package
• Restart PHP-FPM / Apache and verify
• Apply temporary settings anywhere a patch isn’t available yet
• Plan an upgrade for anything on PHP 8.1 or older
• Look for signs of compromise

Running several servers or apps and not sure where to start? Get in touch and we can help you audit and patch them.

Sources: PHP security advisory, CERT-EU advisory 2026-018, Cybernews.