PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what it is, who is affected and how to patch

On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities in the PHP runtime itself, tracked as CVE-2026-109618 and CVE-2026-109619 and known together as PHP2Shell. Both allow an unauthenticated attacker to run code on a web server, and both sit below the application, so they affect WordPress, Drupal, Laravel, Magento and custom PHP alike.

PHP runs a very large share of the web, and attacks were seen before the patches were out. This post explains what PHP2Shell is in plain terms, who is affected, what is and is not known about exploitation, and how to patch properly, including the step most teams miss.

What PHP2Shell is

Both flaws come from the same root weakness: when a PHP request ends abnormally, PHP can leave memory in a state it should not be in, and something later trusts it. BleepingComputer and Help Net Security describe them like this:

• CVE-2026-109618, remote code execution via out-of-memory corruption. Running out of memory can interrupt PHP while request data is only partly set up. The clean-up at the end of the request can then treat that half-built data as valid.
• CVE-2026-109619, remote code execution via stale global state. Internal state belonging to one request can survive after its memory has been freed. A later request handled by the same worker process can use that stale state before it is reset. This is a classic use-after-free, and it can also leak memory from other people's requests.

In both cases the result is code running with the privileges of the web server's worker process. Both are rated CVSS 9.2, critical (see Wiz's entry). According to BleepingComputer, the flaws were found by researchers at Calif, OpenAI and Wiz.

The most serious detail concerns Apache with mod_php. The PHP team said the risk is highest there, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs". In other words, a secure application does not protect you. The attack happens before your code is reached.

Who is affected

The short answer is almost every PHP installation that serves web requests. The PHP advisory, as summarised in Vercel's bulletin, covers PHP 5.4 and later in default configurations, across every common way of running PHP:

• PHP-FPM, behind nginx, Apache or anything else
• Apache with mod_php, the highest-risk setup
• php-cgi
• FrankenPHP
• LiteSpeed

How easily it can be exploited varies with the runtime and configuration, but none of these setups is safe without the patch. Using a different web server or framework does not replace patching.

A few groups are easy to overlook:

• Anyone on PHP 8.1 or older. These branches no longer get official releases. There are minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and long-term support vendors ship their own fixes, but otherwise the answer is to upgrade.
• Appliances and vendor products with PHP inside. As of 22 October, Help Net Security reported that Palo Alto Networks considered all PAN-OS and Panorama versions affected, with no fixed releases yet, while Fortinet and Cisco were still checking their product lines. Expect more vendor advisories over the coming weeks.
• The forgotten WordPress site. Marketing microsites, old campaign pages and staging copies are usually the least patched PHP a company runs.

BleepingComputer cites a VirusTotal estimate of more than 5.1 million PHP hosts exposed to the internet.

Is PHP2Shell being exploited?

Yes, though the public picture was still taking shape at the time of writing.

• Before the patches. Help Net Security reports that Amazon's honeypot network recorded an exploitation attempt on 17 October, four days before public disclosure. How the attacker had the details that early is not known. Cloudflare's CTO also said the company was already seeing early attacks before the releases shipped.
• After the patches. Vercel's bulletin says working public exploits are available and that exploitation attempts have been reported across the industry.
• Disagreement. Some security vendors said on 21 October that they had seen no verified public proof of concept or confirmed compromise. Reports moved quickly that day, so plan on the assumption that working exploits exist.

The UK's National Cyber Security Centre told organisations to update immediately or take affected systems offline. When a national agency suggests switching servers off, treat the issue as urgent.

How to patch PHP2Shell properly

1. Upgrade the runtime

The fixed releases are:

On a distribution package, check your distribution's security tracker. Debian, Ubuntu and Alpine, for example, publish fixes under their own version numbers, so 8.1.2-1ubuntu2.28 can be patched even though it does not match the table.

Updating WordPress, its plugins or your Composer dependencies does not fix PHP2Shell. The flaw is in the runtime, not in the application.

2. Patch what actually serves traffic

This is the step most teams miss. The PHP you see on the command line is often not the PHP that serves your website. php -v reports the CLI binary. Your site may be served by a separate PHP-FPM pool, an Apache module, or a container built months ago from an old base image.

• Check the version the web server actually uses: php-fpm -v, or a temporary phpinfo() page that you delete straight afterwards.
• Restart the workers. PHP-FPM and Apache keep the old code in memory until they restart.
• Rebuild containers from an updated base image and redeploy. Patching the host does nothing for a container that bundles its own PHP.
• Updating a developer's laptop or a CI image is not the same as updating production.

3. Use temporary mitigations only to buy time

If you cannot patch today, BleepingComputer lists stop-gap settings from the PHP team. For CVE-2026-109618, they involve the memory limit, a low post_max_size and container memory limits. For CVE-2026-109619, they involve setting session.upload_progress.enabled=0 and restarting workers, plus fatal_error_backtraces=0 on PHP 8.5. Hiding errors with display_errors or @ does not help.

Web application firewall rules help too. Cloudflare deployed initial rules for all plans, including free ones, and Vercel applies its own automatically. Both say plainly that this reduces exposure and does not replace patching. A WAF only protects traffic that passes through it, so anyone who can reach your PHP origin directly gets past it.

PHP core developer Gina Peter Banyard warned that no mitigation fully blocks these attacks. The patch is the only fix.

4. Check whether you were already hit

If an internet-facing PHP server was unpatched after 17 October, especially one running mod_php, do not assume it is clean just because it is patched now.

• Look for new or recently modified PHP files in web roots and upload folders, unexpected cron jobs, and new user accounts.
• Review outbound connections from web servers. A web worker that starts calling unfamiliar hosts is a strong signal.
• Searchlight Cyber has released an open-source php2shell-scanner that tests whether a host is exposed to both CVEs. Use it on your own systems only.
• If you find signs of compromise, rebuild the server rather than cleaning it, and rotate every secret it could read: database passwords, API keys and cloud credentials in .env files or environment variables. Stolen API keys, AI provider keys above all, are now among the first things attackers take.

The wider lesson

PHP2Shell is a reminder that "the application is up to date" and "the system is up to date" are different statements. Most teams track framework and plugin versions closely and know much less about the runtime underneath, the base image it came from, or which forgotten server still runs it.

Teams that came through this week calmly could answer three questions within an hour: where is every PHP runtime we run, which version serves traffic on each, and how fast can we rebuild and redeploy it. If your team could not, PHP2Shell is a good reason to build that inventory now, before the next critical CVE.

Details in this post come from the PHP security advisory as reported by the sources linked above, published by 24 October 2026. Exploitation reports and vendor advisories are still changing, so check the latest guidance from your distribution and vendors.