PHP2Shell: Where Your Defenses See It and Where They Don't

Updated October 27, 2026: published with every fact checked on October 26, 2026. The Updates section at the end logs each change.

What happened?

The flaws sit in the PHP runtime, not in application code, so updating WordPress or your own code doesn't fix them. In CVE-2026-109618, PHP's advisory says, out-of-memory handling can interrupt PHP while request data is only partly initialized, and cleanup may then treat invalid data as valid. In CVE-2026-109619, request state can outlive its memory, and a later request on the same worker may use it. Both allow unauthenticated remote code execution and score 9.2 under CVSS v4.0 (CVE-2026-109618, CVE-2026-109619).

Every PHP installation that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php the highest risk, with a demonstrated exploit that triggers before any application code runs. The Hacker News puts the affected range at nearly every version back to PHP 5.4 (October 21).

PHP shipped fixes on October 21 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Branches 7.4, 8.0 and 8.1 got only PHP's minimal source backports and distribution or long-term support packages. PHP 7.3 and older, PHP 5 included, have no fix (watchTowr FAQ, updated October 23).

Attempts started before the fix. AWS reported one on October 17 (Datadog Security Labs, updated October 23). Details leaked on October 20 (watchTowr), PHP released the fixes on October 21 at 14:00 UTC and watchTowr saw exploitation in the wild that day. The Hacker News reported that the credited researchers, among them Calif and Wiz, used AI models to turn long-standing flaws into working exploits in about a week.

Where does it stand now?

As of October 26, 2026. The counts below come from different sources and measure different things.

Attempts came at volume. Cloudflare saw tens of thousands of exploit attempts about 45 minutes after disclosure and millions by early October 22, according to The Hacker News (October 23). The same report covered attempts to install a Mirai-derived botnet, which hadn't succeeded at the time.

Working exploits followed. VulnCheck chained the two flaws to bypass ASLR on x86-64, and of the hundreds of proof-of-concept repositories it found on GitHub, only a few were real (VulnCheck, updated October 23). On October 24, researcher Adel Karimi's honeypots recorded 35 shells on a single-worker mod_php setup he called "intentionally favorable" (SecurityWeek, October 26).

A state-linked actor is staging. CYFIRMA reports a suspected North Korean state-nexus actor staging 216 target hosts. It holds high confidence in the state nexus and moderate confidence in a Lazarus link, and it has seen "no confirmed mass successful exploitation" by that actor (CYFIRMA, version 3, October 24).

Governments moved early. Agencies in the US, UK, EU, Canada, Australia and Japan urged patching. The FBI and NSA advised taking systems offline that can't be updated promptly, and sites in Finland, the Netherlands, Belgium and France went offline or partly unavailable, some as a precaution (The National News Desk, October 21). CISA's alert, revised October 26, says to take PHP systems offline until they're patched if you can't update right away or still run PHP 8.1 or older.

CISA now lists both as exploited. It added both CVEs to its Known Exploited Vulnerabilities catalog on October 26, with an October 29 due date and a flag for forensic triage.

No confirmed compromise of a real organization. None of the sources cited here reports one as of October 26. Unit 42 described an intrusion at a European government agency on October 23 and retracted it on October 25: "We are unable to confirm that initial access is associated with the specific PHP2Shell CVEs" (Unit 42).

A third flaw is open. CVE-2026-115560, disclosed on October 23, needs an unusual mix of configuration and application code, and the October 21 releases don't fix it. PHP plans a fix in its next regular release and suggests session.upload_progress.enabled=0 until then (PHP).

The exposure is wide. VulnCheck counts 2,608,039 internet-facing PHP hosts, 99.998% of them vulnerable or likely vulnerable and about 42% on end-of-life branches with no official patched release (October 21, updated October 23). Other firms' larger totals count different things, so they don't compare (The Hacker News, October 23). The cost landed before any confirmed breach: sites went dark, emergency patching started and the end-of-life hosts have no official fix to apply.

A flaw already under attack when it goes public isn't rare. Of the 491 vulnerabilities newly named as exploited in the first half of 2026, attackers were already exploiting 141 when those flaws went public, per the Zero Day Clock, read October 26.

What should you do this week?

In this order.

1. Inventory every PHP install, including the PHP that vendor products, appliances and containers bundle, as Canada's Cyber Centre advises.
2. Patch, then restart every worker. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's fixed package, then restart every PHP worker or redeploy the container. Distributions can backport fixes without changing the version number, so check the changelog for the CVE. PHP 8.2 reaches end of life on December 31, 2026 (PHP).
3. Take the distribution or LTS route for 7.4, 8.0 and 8.1. Use your distribution's or long-term support vendor's package, or build from PHP's minimal backports, and plan the move to a supported branch.
4. Plan the upgrade for 7.3 and older, where there's no fix. Until then, cut internet exposure or limit who can reach those servers, as watchTowr recommends. How to protect servers you can't patch covers compensating controls.
5. Treat settings as stopgaps. PHP says its interim settings, memory_limit=-1 and session.upload_progress.enabled=0 among them, "reduce exposure to specific attack paths but do not make an installation safe."
6. Hunt back to October 17, the earliest known attempt, as CYFIRMA advises: new web shells, unexpected cron jobs and new accounts tied to PHP processes. Datadog treats a shell launched by a web worker as the strongest sign, once you know which child processes your apps start legitimately. A successful exploit can return HTTP 200 and leave the worker running.
7. Test with vendor-verified checks, not proof-of-concept code from GitHub.

What does it mean for the stack you have?

Each layer sees a different part of the attack and goes blind somewhere, as Figure 2 shows.

The edge sees the request. WAF, IPS and CDN rules match known exploit patterns, and Cloudflare's were running before disclosure. Its own post still tells customers to patch, and says its rule for CVE-2026-115560 misses sites that renamed the upload progress field (updated October 23). A variant the rule doesn't recognize, or traffic that reaches the origin another way, goes through.

The flaw lives inside the PHP process. The memory corruption happens while PHP sets up or cleans up a request, and under mod_php that's before any application code runs. Only the patch reaches it.

Host controls see what crosses into the operating system: a new process, a file written or run, a network connection. EDR, application control and kernel-level enforcement all work at this boundary, each asking a different question.

Code that stays inside PHP looks like the app. Reads through the application's own database connection, using only what the PHP process already has, make no change a host control can tell apart from normal work. That holds for every host control, Mimic Networks included.

mod_php widens what counts as normal. The process an attacker lands in is Apache itself, so normal covers everything httpd does. A php-fpm pool for each application, under its own account, narrows normal for every host control. Patch mod_php servers first.

The data is what the PHP process can reach: database credentials, API keys and cloud secrets. If a server was exposed, rotate what it could read.

What should you ask about the tools you're considering?

Put the same seven questions to every vendor, Mimic included. A good answer is specific, measured and admits a limit.

1. Where does the control sit? At the edge, inside the PHP process or at the operating system boundary.
2. What does it see when an attack never leaves the PHP process? If the answer is everything, ask how.
3. What does it need before it protects? A rule for this CVE, a learning period or a baseline. Ask how long that takes.
4. Which operating systems and distributions does it support? Check the list against where your PHP runs.
5. How does it treat an app that legitimately runs shell commands? Block every shell and those apps break. Allow every shell and the control misses the attack.
6. How is a safeguard tested before it goes live? Ask to see what it would block on your own servers first.
7. How long did protection take after disclosure? Ask for timestamps, from the advisory to a rule running on a customer's server.

Where does Mimic Networks fit?

At the operating system boundary, on the servers it supports. Mimic Networks' Virtual Patching works in two forms, and both require baselining. Disruption blocks the specific mechanism an analyzed vulnerability depends on, so the exploit doesn't succeed. Containment limits what an exploit can do once it lands, so one safeguard can cover a whole family of exploits. It's part of Mimic's known-good enforcement approach.

On a server Mimic Networks protects, containment keeps the PHP worker inside its known-good behavior, so what an attacker tries next stops at the point of execution when it falls outside that baseline. Mimic doesn't stop the memory corruption itself, or activity that never leaves the PHP process. Mimic runs on Windows Server 2016 and later and Red Hat Enterprise Linux 8 and later, so PHP servers on Ubuntu, Debian and other distributions fall outside that list.

Before a Virtual Patching safeguard goes live, Mimic replays it against the host's recorded behavior to show what it would block. Mimic runs alongside EDR. The difference is the question each asks at the kernel: EDR asks whether activity matches an attack it recognizes; Mimic asks whether the change was authorized.

For PHP 7.3 and older, an end-of-life runtime is an end-of-support application by another name. How to Protect End-of-Support Applications on Supported Servers covers finding it, deciding its future and protecting the one you keep.

Virtual Patching closes the exposure that AI-accelerated vulnerability discovery opens before a vendor patch exists. It doesn't replace the patch. For PHP2Shell, the patch is the fix.

Updates

October 27, 2026: Published, with every fact checked on October 26, 2026, including CISA's Known Exploited Vulnerabilities listing that day and Unit 42's retraction on October 25.