PHP2Shell: Two Critical PHP Flaws and the Old PHP Nobody Can Patch

On October 21, 2026, the PHP project shipped emergency releases for two flaws now known as PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both let an attacker who has no login run code on a server that uses PHP to answer web requests. Both are rated 9.2 out of 10. Governments across Europe took websites offline the same afternoon rather than wait to find out whether they were exposed, as the BBC reported.

The patch is the easy part. The hard part is that these bugs live in the language runtime, not in anyone’s application, and most of the PHP running today is on versions that will never get an official fix. Qualys counted 155 million PHP installations with a known version across its customers, and 71% of them were on end-of-life branches.

Our take: PHP2Shell is a patching emergency for the next week and an inventory problem for the next year. If you cannot list every place PHP runs in your estate, including inside appliances and control panels, you cannot say you are patched.

Key takeaways

• PHP2Shell is two bugs, CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2, both unauthenticated remote code execution with the web worker’s privileges.
• The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 get only source backports, and PHP 7.3 and older get nothing.
• PHP runs 69.3% of websites whose server language is known, and 34.7% of those sites are on PHP 7 or older, according to W3Techs as of October 22.
• Apache mod_php is the highest-risk setup: the demonstrated attack fires before your application code runs, so clean code does not protect you.

What PHP2Shell actually is

PHP keeps a pool of worker processes alive and reuses each one for many requests. Both bugs exploit what happens when a request goes wrong partway through.

CVE-2026-109618, memory corruption on out-of-memory. When an allocation fails, PHP can abandon a request before its internal data is fully set up. The cleanup code then trusts that half-built data. According to Rapid7’s analysis, a crafted multipart request can exhaust memory even when its size looks within the configured limits. Under Apache mod_php, cleanup runs even when request startup fails, which is why the attack works before any application code is reached.

CVE-2026-109619, use-after-free across requests. A worker can carry state (errors, sessions, objects) that still points at memory freed at the end of an earlier request. The PHP advisory describes it as a producer and a consumer: one request leaves stale state behind, usually through a fatal error or timeout, and a later request on the same worker reads it. The confirmed paths go through PHP 8.5’s fatal error backtraces (on by default) and session upload progress (also on by default). The advisory lists memory disclosure as an impact alongside code execution, so secrets held in worker memory are in play too.

PHP names PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as in scope. The PHP team itself says no configuration change fully mitigates either bug.

Why a flaw in the language is worse than a flaw in an app

Most web vulnerabilities live in application code: a WordPress plugin, a forgotten admin page, a bad SQL query. You can audit that code, and a secure coding culture genuinely reduces it. A runtime flaw ignores all of that. If the interpreter can be broken by a malformed request before your code even runs, the quality of your code is irrelevant.

That makes the blast radius the whole PHP install base. Drupal, Joomla, WordPress, Laravel and Symfony sites are all exposed through the same door. So is PHP you may not think of as PHP: it ships inside hosting control panels such as cPanel and Plesk, network appliances, and some Windows applications. CISA’s alert tells organizations to include PHP embedded in other software in their inventory, because “it may not be easy to see.”

PHP has been here before, and the pattern is instructive. The serious PHP-level bugs of the last decade sat in how PHP connects to the web server, not in the language syntax. CVE-2019-11043 let a crafted URL take over nginx servers running PHP-FPM and was exploited within days. CVE-2024-4577, a bypass of a 2012 php-cgi bug, hit Windows servers and was later tied to ransomware in CISA’s Known Exploited Vulnerabilities catalog. PHP2Shell follows the same line: the request handling layer, the part every PHP site shares.

Two more details deserve attention. First, the flaws are old. Affected versions reach back to PHP 5.4 from 2012, and the out-of-memory issue was spotted in a 2024 audit but left unfixed because developers could not agree on a fix and nobody had a working exploit. Second, AI found them. Calif reported the first bug on August 11 while working with OpenAI, and Wiz reported the second on August 24, both using AI models, Al Jazeera reported. Wiz said the flaws would have been very hard for a human to exploit. That is the shift we wrote about in The Attackers Got AI Before We Did: bugs that sat quietly for a decade are now within reach, for defenders and attackers alike.

How the week unfolded

The plan was a coordinated disclosure on October 22. It did not hold. Details leaked on social media on October 20, and the PHP team moved the release forward to October 21 at 14:00 UTC. watchTowr says its honeypots saw exploitation in the wild from that day. Amazon’s security chief CJ Moses said Amazon had spotted an exploitation attempt on October 17, four days before the patches, and that it was unclear how the attacker knew.

Reports on active exploitation still disagree, and it is fair to say so. Cloudflare’s CTO said the company was seeing early attacks and updating firewall rules as a stopgap, per The Next Web. CISA said it had not observed exploitation when it published its alert, and as of October 22 neither CVE was in its Known Exploited Vulnerabilities catalog. Rapid7 found multiple public proofs of concept by October 22, but each worked only on a narrow mix of operating system, PHP version and web server, and none was broadly reliable. Attack complexity is rated high for a reason.

Governments did not wait to find out. The Netherlands’ national cyber agency took its own site offline first, followed by Overheid.nl, the Port of Rotterdam and several hospitals. Finland’s state IT centre Valtori shut public government web services, Germany’s ITZBund pulled several sites, France’s Interior Ministry pulled prefecture sites, and the Wikimedia Foundation took some PHP systems down until they were patched. Several said they had seen no sign of a breach. Going dark was a precaution, and a reasonable one when you cannot quickly prove what you run.

The real exposure is the PHP you forgot about

W3Techs data shows how long PHP’s tail is. Of all PHP sites, 65.3% run PHP 8, 26.9% run PHP 7 and 7.7% still run PHP 5. Every PHP 7 and PHP 5 branch is past end of life. Only four branches get official fixes for PHP2Shell, and PHP 8.0 and 8.1 sites are hiding inside that 65.3% too.

Here is where each branch stands:

PHP branch	Official support	PHP2Shell fix
8.5	Active until Dec 31, 2027	8.5.12
8.4	Active until Dec 31, 2026	8.4.27
8.3	Security fixes until Dec 31, 2027	8.3.36
8.2	Security fixes until Dec 31, 2026	8.2.35
7.4, 8.0, 8.1	End of life	Source backports only, or a distribution or LTS vendor package
7.3 and older, incl. PHP 5	End of life	None. Upgrade or take offline.

Two traps hide in that table. PHP 8.2 loses security support on December 31, 2026, ten weeks from now, so patching it buys you time, not safety. And distribution packages may keep older version numbers while carrying the backported fix, Qualys notes, so a version string alone can make a patched server look vulnerable or the other way round. Check the package changelog or your distribution’s advisory, such as Ubuntu’s USN-8948-1.

Patching was slow at the start. Qualys saw 199,000 installations patched in the first 12 hours, out of 155 million. That is not a criticism of anyone. Patching runtimes means restarting services, and restarting services means change windows. It is a reminder that exposure lasts weeks after a fix ships, which is exactly the gap we described in AI Broke Vulnerability Management.

What to do this week

1. Inventory every PHP runtime. Web servers, containers and base images, CI images, hosting panels, appliances and vendor software that bundles PHP. Start with anything reachable from the internet.
2. Patch, then restart every worker. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s fixed package. A patched binary does nothing until old PHP-FPM, mod_php and php-cgi processes are gone.
3. Prioritise Apache mod_php. It is the setup where the demonstrated attack lands before application code runs.
4. Isolate what you cannot patch. CISA, CERT-EU and the UK’s NCSC all advise taking PHP systems offline if they cannot be patched quickly. If that is impossible, restrict who can reach them and put a web application firewall in front as partial cover.
5. Use the temporary mitigations, knowing their limits. PHP’s advisories suggest disabling session.upload_progress.enabled, setting fatal_error_backtraces=0 on PHP 8.5, lowering post_max_size, and enforcing memory_limit=-1 from server configuration the application cannot override. All of them must be applied before request parsing, need a full worker restart, and cover only the confirmed paths. Do not use RLIMIT_AS or RLIMIT_DATA; Rapid7 notes they can trigger the vulnerable path.
6. Rotate secrets on anything that was exposed. Because the bugs allow memory disclosure, treat database passwords, API keys and session signing keys held by unpatched PHP workers as possibly read.

What an attack looks like in your logs

Clean logs do not prove you are safe; the advisory says so directly. Hiding errors with display_errors or @ does not stop the stale-state bug either. Watch behaviour instead:

• PHP workers spawning processes. php-fpm, httpd or apache2 starting sh, bash, curl, wget or python. CISA calls this out by name.
• Worker crashes. Segmentation faults and out-of-memory kills in PHP logs, especially clustered around large or odd multipart POST requests.
• New files in the web root. Freshly written .php files in upload folders or caches are the classic web shell sign.
• New outbound connections from web servers to hosts they have never talked to, which is how tools get downloaded and data leaves.
• Use of credentials from places they have never been used, if secrets were read from memory.

How Jutsu helps when the bug is in the runtime

No product patches PHP for you. What helps is knowing where you are exposed and catching what happens next.

• Exposure runs an automated external assessment of your domain from public signals in around ten minutes, so you see the internet-facing attack surface an attacker would scan first, with a prioritised fix list.
• The Jutsu platform ingests alerts from Wazuh, Google Workspace and syslog, and its AI agents enrich, triage and correlate them into incidents. A web worker spawning a shell, a new PHP file in an upload folder and an outbound connection to a fresh host are three weak signals; grouped into one incident they are a compromise. Uncertain cases escalate to your analysts, and response actions such as blocking an IP or isolating a host are logged and reversible.
• Red Team runs MITRE ATT&CK-mapped scenarios, such as C2 beacons and lateral movement, against authorized targets and measures which ones your SOC caught. That is how you find out whether the post-exploitation steps above would actually raise an alert.

For background, see what an AI SOC is. If you want to see your own external footprint, the Free plan needs no credit card.

The bottom line

PHP2Shell is serious, but it is also fixable for anyone on a supported branch who patches and restarts this week. The organisations that will still be exposed in December are the ones running PHP they never knew they had. You cannot patch what you have not counted.

FAQ

What is PHP2Shell?

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed and patched on October 21, 2026. Both allow unauthenticated remote code execution on servers that use PHP to handle web requests. Both are rated 9.2 under CVSS v4.0.

Which PHP versions are affected by CVE-2026-109618 and CVE-2026-109619?

All PHP versions from 5.4 up to the fixed releases are affected. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4, 8.0 and 8.1 get only source backports or vendor packages, and PHP 7.3 and older have no fix at all.

Is my WordPress site vulnerable to PHP2Shell?

If the server running it uses an unpatched PHP version to serve web requests, yes. The flaw is in PHP itself, so it does not matter how well WordPress or your plugins are maintained. Ask your host which PHP version and package you are on and whether workers have been restarted since the fix.

Is PHP2Shell being exploited?

Reports differ. watchTowr and Cloudflare say they saw exploitation attempts from October 21, and Amazon reported an attempt on October 17. CISA had not observed exploitation as of its October 21 alert, and Rapid7 found the public exploits unreliable outside narrow lab setups. Patch as if it is being exploited.

Can I mitigate PHP2Shell without updating?

Only partly. PHP’s temporary mitigations, such as disabling session upload progress and fatal error backtraces, block the confirmed attack paths but not every variant. The PHP team says updating is the only complete fix. If you cannot update, restrict access or take the system offline.