php2shell: What the Critical PHP RCE Vulnerabilities Mean for Your Infrastructure

What php2shell is

php2shell is the nickname for a pair of vulnerabilities in PHP’s Zend Engine, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both at CVSS v4.0 9.2. (Some early leaked reports circulated a 10.0 figure; the official rating is 9.2. Treat the 9.2 as authoritative.)

The two flaws sit at different points in the request lifecycle:

• CVE-2026-109618: after a memory allocation fails, PHP leaves invalid data behind for its cleanup routine to process. An attacker can trigger that failure with a crafted request and get code execution while PHP cleans up.
• CVE-2026-109619: a PHP worker can reuse stale state left over from a previous request.

The important part for anyone running PHP: the request never has to reach your application code. A security researcher’s reproduction triggers the fault with a single unauthenticated HTTP POST, and PHP runs the attacker’s command while handling the failed request. Any PHP script exposes the vulnerable path, including one that only prints a response. You cannot code your way out of this in your application. It is in the interpreter.

Who is affected

PHP versions 5.4 through 8.5 are vulnerable. That is effectively every PHP deployment that has not already applied the 21 October patch. Because the bug is in PHP core, it cuts across the whole ecosystem:

• WordPress and WooCommerce sites
• Drupal
• Magento / Adobe Commerce storefronts
• Laravel, Symfony and other framework apps
• Custom PHP services and internal tools
• Anything behind a PHP-FPM or mod_php web server

If a server runs PHP and is reachable from the internet, assume it is in scope until you confirm the version.

The fix: patch now

The patched releases are:

If you are on a supported branch (8.2–8.5), update to the version above and restart PHP-FPM or your web server. On most managed platforms this is a package update:

# Debian / Ubuntu (adjust the version to your installed branch)
sudo apt update && sudo apt upgrade php8.3 php8.3-fpm
sudo systemctl restart php8.3-fpm

# RHEL / Amazon Linux (via Remi or your repo of choice)
sudo dnf upgrade php php-fpm
sudo systemctl restart php-fpm

# Confirm the running version after restart
php -v

Check the version PHP-FPM actually serves, not just the CLI, since they can differ:

# What the web tier is running
php-fpm -v
# Or, from a page you control:
# <?php echo PHP_VERSION;

There is no reliable mitigation short of patching or taking the host offline. A web application firewall may blunt some payloads, but because the trigger is a malformed request handled before your app runs, do not treat a WAF as a substitute for the patch. As of the official advisories, no in-the-wild exploitation had been confirmed, but working proof-of-concept exploits exist in security research labs, so the window between now and active attacks is short.

If you are on PHP 8.1 or older: this is a modernisation decision

Here is the part that turns php2shell from a patch into a project. PHP 8.1 and every version below it are end of life and will not receive a fix. PHP 5.x and 7.x have been unsupported for years. A large population of internet-facing servers still runs them.

If that is you, apt upgrade does not solve the problem. There is no patched 7.4 to move to. Your realistic options are:

1. Upgrade the PHP branch to a supported, patched version (8.2+). This is the right end state, but a jump from 7.x to 8.x is not transparent: deprecated functions, changed type behaviour, and dependencies that need their own upgrades all surface during the move.
2. Modernise the platform around it. In practice, servers stuck on EOL PHP are usually stuck on EOL everything: an old OS, an unmanaged VM, no clean deployment path to apply updates quickly. The version bump is a good moment to move the workload onto something you can patch in minutes next time (containers on ECS or EKS, or a managed runtime) instead of a pet server nobody wants to touch.

The honest framing for a stakeholder: you were always going to have to leave EOL PHP. php2shell just set the deadline. The cost of staying is now an unpatched, unauthenticated, remote-code-execution hole on a public server.

What to do this week

1. Inventory. List every host, container and managed service that runs PHP, and record the exact version each serves from the web tier. Do not forget staging, admin panels, and that one legacy box.
2. Patch the supported ones. Anything on 8.2–8.5 goes to the patched release immediately.
3. Triage the EOL ones. For PHP ≤ 8.1, decide per workload: upgrade the branch, migrate the platform, or take it offline until you can. Do not leave a public EOL PHP host running untouched.
4. Verify. Re-check the served version after patching and confirm the host is not already compromised (unexpected processes, new cron entries, modified web root files).

For patching supported versions, see above and act today. For the EOL workloads that cannot simply be patched, the fix is a migration and modernisation conversation. We help teams move legacy PHP off end-of-life servers onto patchable, managed infrastructure. See Cloud Migration, and if you want a structured look at the whole environment first, our Well-Architected Review.

Running PHP workloads and not sure where you stand?

Book a free 30-minute call. We'll help you find vulnerable PHP, patch what can be patched, and plan the move off anything end-of-life.

Book a call Send us a message