PHP2Shell explained: the PHP core bugs attackers hit four days before the patch

Most critical vulnerabilities follow a script: researchers report privately, vendors patch, and the world finds out on disclosure day. PHP2Shell broke the script at every step. Details leaked early, attackers started probing before a patch existed, and within a week CISA was warning that the bugs were being chained with a Linux kernel exploit to get root.

PHP still runs a large share of the web, and that's why this one matters.

What happened

On 21 October 2026, the PHP project shipped emergency security releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities in PHP itself that can allow unauthenticated remote code execution. Both are rated 9.2 under CVSS v4.0 by PHP's security team. NVD has since scored them 9.8 under CVSS v3.1.

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): RCE via out-of-memory (OOM) corruption.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): RCE via stale global state.

PHP's advisory is blunt: there are no complete mitigations, and updating is the only safe choice.

"PHP2Shell" isn't PHP's name for the bugs. It comes from an exploit tool shown in screenshots that circulated before disclosure, and the name stuck.

The timeline

17 Oct: Amazon Threat Intelligence says the first exploitation attempts started, from multiple actors and four days before any patch existed. Amazon says it's unclear how the attackers got the information.
20 Oct: details leak publicly. PHP posts advance notice of a security release the next day at 14:00 UTC, and CERT-EU issues an advisory. PHP moved the release forward because of the leak.
21 Oct: fixed versions are released.
23 Oct: PHP publishes an informational advisory about a separate, unlikely RCE path (CVE-2026-115560) involving session upload progress. Its fix is coming in the next regular release.
26 Oct: CISA adds both CVEs to its Known Exploited Vulnerabilities (KEV) catalog and orders US federal civilian agencies to patch within days. A researcher at Perplexity reported a honeypot capturing RCE against Apache mod_php running PHP 8.4.26.
28–29 Oct: CISA adds Fragnesia (CVE-2026-46300), a Linux kernel privilege-escalation bug, to KEV and warns it's being chained with PHP2Shell. Dream Security reported a campaign that used the chain to root 25 servers across the US, Japan, Taiwan and South Korea.

Update (1 Nov 2026): those 25 targets were firewalls. SecurityWeek reports that Dream found the victims by searching for about 19,000 internet-facing firewalls from one vendor, and that two of the rooted devices sat in a US government-affiliated network where the attackers went on to pull credentials. On 29 October, Palo Alto Networks' Unit 42 confirmed that PHP2Shell is being exploited against PAN-OS management interfaces exposed to the internet. Palo Alto says that exposure is off by default and affected about 0.02% of its customers, and it has shipped PAN-OS fixes. Dream calls the operation Chinese-nexus but hasn't attributed it to a named group.

Not every attempt succeeded. Several security firms, including Cloudflare, watchTowr and Patchstack, logged failed attempts before disclosure, and PHP said the early leaked proofs of concept didn't work. But CISA doesn't add bugs to KEV without evidence of exploitation.

The bugs, in plain language

PHP hasn't published full technical write-ups, and this post won't go further than the advisories. At a high level:

OOM corruption (CVE-2026-109618). When PHP runs out of memory mid-request, it doesn't unwind neatly. It jumps out of the current operation to abort the request. If that happens at exactly the wrong moment, internal data structures can be left half-updated. An attacker who can push a request to its memory limit at a chosen point may be able to turn that inconsistency into memory corruption, and from there into code execution.

Stale global state (CVE-2026-109619). PHP workers in pools like PHP-FPM serve many requests over their lifetime. If some global state isn't properly reset, data from one stage of processing can be used later when it shouldn't be. Bugs like this are hard to spot in review because each piece of code looks fine on its own.

Neither bug needs a login, and neither depends on your application code being vulnerable. The flaw is in the runtime.

Why the Linux chain matters

Getting code execution in PHP usually means running as the web server user, such as www-data. That's bad, but limited. Fragnesia is a logic flaw in the Linux kernel's XFRM ESP-in-TCP code, affecting kernels released before 13 May 2026. It lets a local attacker become root.

Unpatched PHP (internet-facing) └─ PHP2Shell → code execution as the web server user → web shell └─ Fragnesia (unpatched kernel) → root └─ full server control, persistence, lateral movement

That's why "we'll patch PHP next sprint" isn't enough. A server with a patched PHP but an old kernel is still exposed to the next web bug, and a server with old PHP and an old kernel can be fully taken over.

Who is affected

Anyone running PHP 8.2–8.5 below the fixed versions. That includes WordPress, Laravel, Drupal and Magento sites, shared hosting and internal tools.
End-of-life branches (8.1 and older) get no fix. They have to be upgraded, not patched. PHP 8.2 itself reaches end of life on 31 December 2026.
Appliances that embed PHP. Firewalls, VPNs, NAS boxes and other devices often run PHP in their admin web interfaces. They need the vendor's firmware fix, and their management pages shouldn't face the internet.
Containers and images built before 21 October. Rebuild them. Base images don't update themselves.
VirusTotal estimates, cited by BleepingComputer, put more than 5.1 million PHP hosts online, about 3.8 million of them with at least one exposed port.

What to do now

# Which PHP is actually running? (CLI and FPM can differ) php -v php-fpm -v 2>/dev/null || php-fpm8.4 -v 2>/dev/null # Check the settings PHP lists as partial mitigations php -i | grep -E "session.upload_progress.enabled|post_max_size|memory_limit"

Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, and restart PHP-FPM or Apache so the new binary is actually used.
If you can't patch immediately, PHP lists partial mitigations: session.upload_progress.enabled=0, a lower post_max_size, and fatal_error_backtraces=0 on 8.5. It also lists memory_limit=-1, but removing the memory cap trades this risk for an easy denial-of-service. Treat all of these as stopgaps.
Set session.upload_progress.enabled=0 until the next bugfix release if your app changes session.serialize_handler at runtime. That's the CVE-2026-115560 case.
Patch the kernel to close the Fragnesia chain.
Review logs back to 17 October, as Amazon recommends. Look for new PHP files in web roots, unexpected outbound connections from web servers, and unusual worker crashes.

What developers and teams can learn

Disclosure day isn't the earliest exploitation day. Amazon's data shows attackers can be active before a patch exists. Have a way to apply an emergency runtime update within hours.
Runtimes are dependencies too. Teams track npm and Composer packages carefully but often run whatever PHP version the image shipped with.
End of life is a security status. If you're on 8.1 or older, this patch doesn't exist for you.
Defence in depth works. Least-privilege web users, patched kernels and read-only web roots turn a full takeover into a contained incident.

What might happen next (analysis)

This is analysis, not reporting.

Expect a long tail. Web shells planted in the days before servers were patched will outlast the patch itself, so expect cleanup-driven breach disclosures in the coming weeks. The CVE-2026-115560 fix will land in the next regular release and is worth watching. More broadly, after a leaked embargo, expect pressure on open-source projects to tighten how pre-disclosure details are shared with downstream vendors.

Conclusion

PHP2Shell shows everything that can go wrong with a critical bug at once: a leaked embargo, exploitation before the patch, a huge install base, unsupported versions that will never be fixed, and a kernel bug that turns a web compromise into root. The fix itself is simple. Upgrade PHP, patch the kernel and check your logs.

Your turn: how quickly could your team roll out an emergency PHP or runtime update across every server and container image?