PHP2Shell: why a WAF alone won't stop this PHP RCE

On 21 October 2026 at 14:00 UTC, the PHP project shipped emergency fixes for two critical vulnerabilities in the PHP runtime itself, now publicly known as PHP2Shell. The pair, CVE-2026-109618 and CVE-2026-109619, can let an attacker run code on a PHP server without logging in, and together they touch every PHP setup that serves web requests: PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed. The fixes are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A web application firewall (WAF) can slow some attack traffic, but the vendors that explain their rules, Cloudflare, Microsoft, Imperva and Sucuri among them, say plainly that a rule does not replace patching. That caveat does not soften because the traffic happens to come from a signed-in user talking to an AI assistant: on the strongest confirmed attack path, the vulnerable code runs before the application, its login check, or anything it does with a session gets to execute at all.

This post is current as of 22 October 2026 (AEDT). Exploitation status, WAF vendor rule coverage and Australia’s own alert page are all still moving, and we say so where it matters.

The short answer

• What is it? PHP2Shell is the public name for CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state), two memory-safety bugs in the PHP runtime, not in WordPress, Laravel, Drupal or any application built on top of it.
• Is it patched? Yes, in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released 21 October 2026. PHP 8.1 and earlier are end of life and got source-only emergency backports, not an official binary update.
• Does a WAF stop it? Partially, on some vendors, some of the time. Coverage is uneven, and the vendors that explain their PHP2Shell rules call them a stopgap, not a fix.
• Does the AI angle change anything? Not in the way “it’s behind a login” implies: the confirmed mod_php attack path runs before the application’s authentication and session code executes at all. What does change is architecture: AI agents and internal tool calls create traffic that may never reach the edge WAF in the first place.
• Is it being actively exploited? Contested. CISA and Canada’s Cyber Centre said on 21 October they had not observed exploitation, and Huntress found no successful compromise on its customers’ systems. Fastly reports active probing, and Cloudflare says attackers are reworking payloads to get past its rules. New Zealand’s NCSC says it is aware of reports of active exploitation. Neither CVE was on the CISA KEV catalogue at our last check.

Verified timeline

All times are UTC unless stated otherwise.

What is PHP2Shell?

PHP2Shell names two bugs that share one pattern: PHP interrupts itself when something goes wrong, and doesn’t always clean up before a later step, or a later request, reads the mess it left behind.

CVE-2026-109618: RCE via OOM corruption

PHP aborts a request with longjmp() when it runs out of memory. In some contexts, request memory is reachable before it’s fully set up, and if an allocation fails exactly then, PHP leaves that memory invalid for the shutdown procedure to read or branch on. Multipart parsing can reach this state through the shape of a request (headers per part, nested field names, no usable content length), not raw size, which is why the advisory’s primary mitigation, forcing memory_limit=-1, is explicitly described as incomplete.

On Apache’s mod_php, shutdown runs unconditionally, even when startup has failed, “entirely before any application-specific code begins execution.” That’s why the confirmed mod_php exploit is unauthenticated RCE that fires ahead of any login check. PHP-FPM kills the worker when startup fails instead, so the advisory calls FPM merely susceptible by source analysis, with no complete FPM exploit demonstrated.

CVE-2026-109619: RCE via stale global state

This is the cross-request bug that matters for the AI and session question later in this post. PHP keeps state, including error, session, object and extension state, that belongs to one request but can be read by a later one on the same worker. The advisory needs an operation to publish request-owned state globally without resetting it, PHP to free that memory while the worker still refers to it, the same worker to handle another request, and that second request to read the stale state before its own setup resets it.

Two trigger paths are confirmed, both firing before the consuming request’s own initialisation: a diagnostic PHP raises while applying configuration values, and Session Upload Progress, which updates session state while PHP parses a multipart body and is, per the advisory, on by default and needs no call to session_start(). The strongest demonstrated case is PHP 8.5-specific: with fatal_error_backtraces enabled, a fatal error’s backtrace data survives into a later request and is read by that request’s own configuration check before initialisation, which the advisory calls “the basis of the confirmed mod_php exploitation.”

On PHP-FPM, the picture matters if your concern is an authenticated feature such as an AI assistant. Unlike CVE-2026-109618, where FPM is only theoretically susceptible, the session-lifecycle path for CVE-2026-109619 was validated against FPM too: the first, producing request genuinely runs real application code and succeeds, before hitting a fatal error; only the second, consuming request is guaranteed to fire ahead of its own setup, depending on a suitable application operation existing to fail. PHP’s advisory admits it hasn’t enumerated every producer, singling out fatal errors inside operations that call back into application code, with no configuration setting closing every case. That open-endedness matters later.

This is mechanism, not method: what’s above is what PHP’s advisories disclose, not a recipe.

Which PHP versions are affected?

Both CVEs affect PHP 8.2 up to 8.2.35, 8.3 up to 8.3.36, 8.4 up to 8.4.27, and 8.5 up to 8.5.12, per PHP’s own CVE records. Every SAPI that serves web requests is named as at risk: PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP calls mod_php the highest-risk configuration, since that’s where the unauthenticated, pre-application-code exploit is demonstrated.

PHP 8.1 and earlier had already left standard support, so they get no numbered fix. Given the severity, PHP’s security team published minimal source-only backports for PHP 7.4, 8.0 and 8.1, but these aren’t pre-built binaries; your distribution or host has to build them. The Essential Eight Maturity Model separately requires unsupported online services to be removed, so an internet-facing PHP 8.1 service is arguably a second compliance problem.

Don’t trust php -v alone when verifying a fleet: distributions often backport a fix without bumping the version string, so check the distribution’s own advisory number (a Debian DSA/DLA, an Ubuntu USN, a Red Hat RHSA) instead.

What does PHP2Shell actually let an attacker do?

The confirmed impact is unauthenticated RCE with the privileges of the web worker account, on mod_php. The stale-state bug also discloses memory: one path reflects corrupted memory back through the Set-Cookie: PHPSESSID response header, and Imperva, which worked with the researchers ahead of disclosure, says a single request can expose roughly 67 KB of process memory this way, and that what leaks depends on what the worker was handling, which can include sensitive application data. If any internet-facing system of yours ran unpatched PHP, treat it as a possible credential exposure, not only a vulnerability: code execution and a memory leak can both reach the secrets your application uses, so rotate them.

The bug lives in the PHP runtime, not in any application on top of it, so updating WordPress, Laravel, Drupal or Joomla does nothing for it. Laravel’s own Forge documentation says so directly: “Forge’s automatic security updates do not patch PHP.” You have to update the PHP binary, or have your host do it.

The scale follows from how much of the web runs on PHP: cited figures converge on roughly 70% of websites whose server-side language is known. That includes every WordPress, Drupal and Joomla site, even though none of those projects’ own code is at fault.

Is PHP2Shell being actively exploited?

As of 22 October 2026, this is genuinely contested. CISA’s alert states it had “not observed exploitation of these vulnerabilities as of the time of publication.” Canada’s Cyber Centre confirmed a public proof-of-concept exists but reported “no active exploitation… at this time.” Huntress told CyberScoop it had “not observed, or independently confirmed, successful in-the-wild exploitation… on live customer systems,” having checked specifically for the post-exploitation behaviour in the public proof-of-concept and found none. In the same piece, Fastly’s chief product officer said attackers are actively probing and running reconnaissance against PHP applications, and Cloudflare says it watched attackers change their payloads to try to slip past its rules. Probing and attempts are not the same as confirmed compromise, but they show attackers are working on it.

watchTowr’s own messaging pulls in two directions. Its intelligence page marks both CVEs as exploited in the wild, while its head of threat intelligence told Cyber Daily that “whilst nobody has been successful to date, we don’t expect that will last long.” New Zealand’s NCSC went further on the morning of 22 October (NZDT), saying it is “aware of reports of active exploitation,” though that’s secondhand, not confirmed compromise. At our last check, a CISA KEV snapshot dated 21 October, 14:04 UTC, listed neither CVE.

ACSC rates the issue Critical, its highest category. ASD said on 21 October that cyber.gov.au and other government sites had reported outages, and a spokesperson for the Home Affairs Minister confirmed “disruptions to several Australian websites” overnight. No source claims any Australian government system was actually breached, only that PHP-running sites took precautionary or operational hits during a fast-moving release.

Does a WAF stop PHP2Shell?

Partially, and unevenly, which rules out any blanket “a WAF blocks PHP2Shell” claim. Coverage varies by vendor, and even by product line within one vendor:

• Cloudflare turned on default protection for free and paid WAF customers from 03:02 UTC on 21 October, using a new “full transaction detection” capability built for this disclosure that can also inspect the response side of a request.
• Microsoft Azure’s Front Door rule ships disabled by default, with full rollout not expected until 28 October 2026; once enabled, it strips content from the response rather than blocking the request, and “does not generate WAF log entries or hit counts” when it fires. Azure’s older Application Gateway has no managed rule yet, only a manual header-rewrite workaround.
• Fastly’s protection is opt-in: an administrator must find the virtual patch and switch it on.
• Imperva Cloud WAF customers are protected automatically; Elastic WAF and Gateway customers needed a software update first.
• We found no vendor-published, CVE-specific managed rule for AWS WAF or Google Cloud Armor, only generic, pre-existing injection signatures.

Cloudflare, Microsoft, Imperva and Sucuri each say their rule does not replace patching; Fastly’s changelog entry only explains how to switch its rule on. Microsoft’s advisory calls patching the complete remediation, with the WAF rule reducing exposure only while you upgrade. OWASP’s Virtual Patching Cheat Sheet states the principle this incident illustrates: a virtual patch “reduces exposure only for traffic the enforcement layer inspects”, and only against attacks its rules know about; the flaw itself stays in place until you patch.

Why this bug is hard for a perimeter device to catch

The dominant signal here isn’t a malicious payload string, it’s the presence of a legitimate PHP feature, Session Upload Progress, inside an ordinary file upload. Cloudflare says it observed attackers mutating payloads to evade its rules, though no vendor we checked documents a confirmed bypass of a shipped rule, only evasion attempts.

Two structural gaps compound this. Every edge platform we checked caps how much of a request body it inspects: 8 KB on AWS Application Load Balancer and AppSync, 16 KB rising to 64 KB elsewhere on AWS, and a default 64 KB, configurable down to 8 KB, on Google Cloud Armor. Content past that ceiling is invisible to body-matching rules, and what happens to the rest depends on the platform’s oversize-handling setting, worth checking rather than assuming. And the leak half of this bug rides home in a response header, which most WAFs never inspect, which is why Cloudflare and Azure both built new response-inspection capability for this disclosure.

None of this helps if traffic reaches your PHP server without passing through the WAF at all. Sucuri’s advice applies to any CDN-fronted WAF: protection “only works when requests pass through the firewall,” so lock your origin down to accept connections only from your provider’s published IP ranges.

Does Cloudflare protect against PHP2Shell?

Yes, by default, on Cloudflare’s WAF, free or paid, since 03:02 UTC on 21 October. Confirm your Managed Ruleset is in block mode rather than log-only; Cloudflare itself calls the protection defence-in-depth, not a substitute for patching, and none of it helps traffic that bypasses Cloudflare’s network to reach your origin directly.

Why “it’s behind a login” doesn’t help here, and what does

This is the question we were asked to test: if the attack chain runs through an authenticated user’s session with an AI assistant, does a WAF or proxy stop it? The honest answer has one part that holds cleanly, two parts that are plausible architecture rather than documented exploitation, and one part the evidence rules out.

What holds: authentication doesn’t matter on the strongest path. For the confirmed mod_php exploit chain, the vulnerable code runs entirely before the application’s authentication and session-handling code ever executes. Session Upload Progress, the confirmed trigger for the stale-state bug’s session path, needs no call to session_start() at all. An attacker gains nothing, and a defender loses nothing, from a request arriving on a signed-in session rather than an anonymous one, because the bug fires before the application knows who, or whether, anyone is logged in.

A labelled scenario, not a documented attack: the two-request problem. A WAF judges one request at a time. PHP’s advisory confirms that on PHP-FPM, the session-lifecycle path for CVE-2026-109619 needs a first request to run real application code and fail, before a second request on the same worker reads the leftover state. That first request could, in principle, be ordinary authenticated traffic, including something an AI assistant feature triggers, though no source we reviewed shows an AI feature acting as that trigger. The second, consuming request still looks like an ordinary multipart upload touching session state, the same signal a well-tuned WAF rule can catch. So the honest framing is a partial defence, not a zero one: the WAF can’t see what poisoned the first request, but it may still block the second one that cashes it in.

A labelled scenario, not a documented attack: east-west traffic. AI agents, MCP tools, webhooks and other server-side callers routinely talk to internal PHP services directly, without passing through the edge WAF at all. That’s architecture, not anything specific to PHP2Shell: a cron job or a queue worker creates the same blind spot. What AI agents add is more of this internal traffic, plus new callers whose actions can be steered by content they read from elsewhere, the pattern OWASP’s Top 10 for LLM Applications names indirect prompt injection (LLM01) and excessive agency (LLM06). The confirmed EchoLeak vulnerability in Microsoft 365 Copilot, CVE-2025-32711, is the clearest precedent for an LLM’s own output becoming an attack vector once a downstream system trusts it, but it isn’t a PHP2Shell case, and no source bridges that mechanism to this same-worker race. If you’re reviewing agent tool access, our piece on MCP’s authorisation surface covers the identity and scoping problem this traffic creates.

What the evidence rules out: chat history is not the “session” in the advisory. “Session” does two different jobs here. The session state CVE-2026-109619 corrupts is PHP’s own internal session engine and upload-progress bookkeeping, driven by raw protocol fields the engine reads before any application script runs, not the contents of the $_SESSION array an application populates, say with a stored chat transcript. Every trigger in PHP’s advisory is described in engine-level terms, not arbitrary application data, and no primary source names application-level session content, AI-generated or otherwise, as a trigger for either CVE. Treat this as not supported by any source, not proven impossible: a very large $_SESSION payload could in principle feed CVE-2026-109618’s out-of-memory precondition, but so could any oversized upload, and nothing about it is specific to AI content.

The bottom line. A WAF or proxy only sees traffic that crosses it, one request at a time, up to a body-size limit, mostly inbound. AI features add traffic that sometimes doesn’t cross it at all. Patching is the only complete fix, for every client that might send a request, human or automated.

What to do now

Patch first. Update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Verify success by the distribution’s own advisory number, not a bare php -v, since distributions often backport without changing the version string. Rebuild and redeploy any container image bundling its own PHP runtime; patching the host underneath does nothing for the copy baked into the image.

Know your clock under the Essential Eight. The Maturity Model’s patching clause for online services is unambiguous: patches are applied “within 48 hours of release” when vendors assess a vulnerability as critical or a working exploit exists. PHP rated both CVEs critical at release, so by our own calculation, not an ACSC-stated deadline, the window runs from 21 October 2026, 14:00 UTC to roughly 23 October, 14:00 UTC (24 October, 1:00am AEDT). The Model also requires unsupported online services to be removed, so an internet-facing PHP 8.1 service is arguably a second finding.

If you can’t patch inside that window, the interim settings differ by CVE, and conflating them was the most common error in early coverage:

Treat every row as a stopgap. PHP’s own advisories call these measures incomplete, and watchTowr goes further, arguing that .ini-level mitigations for this bug family don’t meaningfully reduce exploitability.

Harden your WAF, don’t just trust it’s there. On Cloudflare, confirm your Managed Ruleset is in block mode. On Azure, check whether the Front Door rule has reached your profile (full rollout completes 28 October) and whether you need the Application Gateway workaround meanwhile. Restrict your origin to accept connections only from your WAF’s published IP ranges, so an attacker who knows your origin can’t go around it.

Inventory what’s calling PHP from the inside. The east-west gap above is architecture, and AI agents are only the newest source of it. If you lack a clear list of which AI features and agents call your PHP services, start there; our guide to finding shadow AI without destroying trust sets out a staged discovery method, including AI features already switched on inside SaaS tools you’ve approved. Then segment service-to-service traffic, route agent tool calls through a gateway you actually inspect, scope each tool to the minimum it needs, and treat model output as untrusted input.

Watch for the signs that matter, not just WAF alerts. CISA and Canada’s Cyber Centre both point at the same signal: a PHP worker spawning a shell, writing into the web root, or making an unexpected outbound connection.

Rotate secrets on anything exposed and unpatched. The confirmed impact includes memory disclosure, so any internet-facing system unpatched during the exposure window should have its credentials and tokens rotated as part of remediation, not treated as resolved by patching alone.

How we can help

If you need an independent view of what your PHP estate, and anything calling into it, does under attack, our penetration testing covers web applications, APIs and perimeter exposure, run by a certified offensive practitioner. If AI agents or LLM-backed features sit inside your estate, our AI offensive security review tests tool abuse, agent privilege escalation and east-west paths the way an attacker would. For a structured, evidence-based view against your broader control set, our security posture assessment is a two-week, fixed-price engagement with Essential Eight maturity scoring, not a self-reported checklist. And if you need a named person accountable to your board for decisions like the patching window above, our fractional CISO gives you that, with no client-manager layer in between.

A checklist for this week

1. Identify every PHP instance you run, including inside containers, and its SAPI (FPM, mod_php, CGI, FrankenPHP, LiteSpeed).
2. Patch to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, prioritising internet-facing systems; verify by advisory number, not php -v.
3. On PHP 8.1 or earlier, apply the source-only backport or take the service offline until upgraded.
4. If you can’t patch immediately, apply the per-CVE interim settings above and restart every worker.
5. Confirm your WAF’s managed rule is active and in block mode, and lock your origin to its IP ranges.
6. Inventory which AI features and agents call your PHP services, and how those calls authenticate.
7. Check logs for PHP workers spawning shells, writing into the web root, or making unexpected outbound connections.
8. Rotate credentials and tokens on any internet-facing, unpatched system from the exposure window.
9. Calculate your Essential Eight 48-hour clock from 21 October 2026, 14:00 UTC, and track it to closure.
10. Confirm with your host, in writing, which PHP version is actually serving production traffic.

Further reading

• php-src Security Advisory: GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• php-src Security Advisory: GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• PHP.net: News Archive 2026, the security release and version announcements
• ACSC: Critical vulnerabilities in PHP
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability
• Microsoft: Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations
• OWASP: Top 10 for LLM Applications 2025
• OWASP: Virtual Patching Cheat Sheet
• ASD: Essential Eight Maturity Model
• NCSC New Zealand: CVE-2026-109618 and CVE-2026-109619 affecting PHP
• ABC News: Australian government sites among those exposed to ‘critical’ PHP software flaw

Frequently asked questions

Is PHP2Shell patched, and which versions fix it?

Yes: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released 21 October 2026. PHP 8.1 and earlier got source-only emergency backports, not an official binary release, so distributions and hosts need to apply them separately.

Does updating WordPress, Laravel or Drupal fix PHP2Shell?

No. The vulnerability sits in the PHP runtime underneath those frameworks. You, or your host, need to update the PHP binary itself.

Does a WAF stop PHP2Shell on its own?

Not reliably. Coverage differs by vendor, several major rules shipped disabled or opt-in, body-inspection limits miss large requests, and the memory-disclosure half of the bug rides home in a response header most WAFs never inspect. Cloudflare, Microsoft, Imperva and Sucuri all say their rules do not replace patching.

Can a long AI chat history trigger PHP2Shell?

No source we reviewed supports this. The “session” state PHP2Shell corrupts is PHP’s internal session engine and upload-progress bookkeeping, not an application’s $_SESSION array. A huge chat transcript could in theory feed an out-of-memory condition, the same as any other large upload, but nothing about that is specific to AI content.

Does PHP2Shell require someone to be logged in?

No, and that’s the point: the confirmed exploit chain on mod_php runs before the application’s own authentication code ever executes. “Behind a login” does not reduce risk for the strongest demonstrated path.

Is PHP2Shell being actively exploited right now?

Contested. CISA and Canada’s Cyber Centre had not observed exploitation as of 21 October 2026, Huntress found no successful compromise on its customers’ systems, Fastly reports active probing, and Cloudflare reports attackers reworking payloads to evade its rules. watchTowr’s own materials send mixed signals, and New Zealand’s NCSC says it is aware of reports of active exploitation. Neither CVE was on the CISA KEV catalogue at our last check.

Where to start

Patch first; everything else here is a stopgap while you do it. If you want an outside view of whether your PHP estate, your WAF configuration, or the agents and tools calling into your systems would hold up against this, talk to us. If you’d rather start with a quick baseline, the AI governance maturity self-assessment takes about ten minutes and gives you a scored starting point against the NIST AI RMF.