Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Critical Unauthenticated PHP RCE Is Being Exploited — ESA Managed Rules Already Block It

Critical Unauthenticated PHP RCE Is Being Exploited — ESA Managed Rules Already Block It

Two critical memory-corruption flaws in PHP's request-parsing path, disclosed on October 21, 2026 and dubbed "PHP2Shell," allow unauthenticated remote.

php2shell_blog_cover
Two critical memory-corruption flaws in PHP's request-parsing path, disclosed on October 21, 2026 and dubbed "PHP2Shell," allow unauthenticated remote code execution on virtually every HTTP-facing PHP deployment. Public exploits exist and in-the-wild attempts were observed even before disclosure. If your workloads sit behind Alibaba Cloud Edge Security Acceleration (ESA), the virtual patches are already in the managed WAF rule set — enabling managed rules is all it takes to block exploitation at the edge.

What is PHP2Shell?

On October 21, 2026 the PHP project shipped emergency releases fixing two critical memory-corruption vulnerabilities that researchers collectively nickname PHP2Shell:

  • CVE-2026-109618 — RCE via POST/multipart parsing. When a crafted request drives PHP into memory exhaustion while parsing a multipart/form-data body, the failure can interrupt a hash-table insertion after internal counters have already been updated. The result is an uninitialized bucket that shutdown cleanup later treats as valid. By grooming the heap, an attacker can place controlled bytes into that bucket and have the cleanup walk a forged array structure straight into a shell-command execution path.
  • CVE-2026-109619 — RCE via stale global state across requests. A PHP worker can retain residual state from a previous request (for example around session upload progress, or fatal-error backtraces on PHP 8.5). A subsequent request handled by the same worker can reuse that stale state, producing a use-after-free condition (CWE-416) that yields memory disclosure and remote code execution.

Both issues are rated Critical — CVSS v4.0 9.2 in third-party advisories and 9.7 in the Alibaba Cloud Vulnerability Database (AVD). Crucially, no authentication is required, and the corruption happens while PHP is still parsing the request, before a single line of application code runs. Application logins, CSRF tokens, or authorization checks in your PHP code provide zero protection: the attacker never reaches them.

Every HTTP-serving PHP runtime is in scope — PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed — on all branches prior to 8.2.35, 8.3.36, 8.4.27 and 8.5.12. mod_php-style deployments are considered the most exposed because failure handling can occur before application logic starts. Working exploits have been demonstrated, public PoC material is circulating, and cloud providers reported scanning and exploitation attempts around the disclosure window.

In practical terms, the attack traffic has a recognizable shape: oversized multipart/form-data POSTs with binary or empty-name fields, abnormally long and deeply nested form-field names sized to make an allocation fail at a chosen moment, and — for CVE-2026-109619 — follow-up requests probing the same worker, often combined with session upload-progress abuse. That shape is exactly what a web application firewall can be taught to spot.

Why "just patch" is not enough for the next 72 hours

The only complete remediation is upgrading to the fixed PHP releases (or vendor backports for the 7.4/8.0/8.1 lines). But for most organizations that is a multi-day project: rebuilding container images, regression-testing applications, coordinating with distribution vendors for LTS packages, and rolling out fleets of workers. Meanwhile the exploits are public and scanning is ongoing.

This is the classic virtual-patching window: place a filtering layer in front of PHP that recognizes and drops the exploit traffic at the edge while the patching program runs. The filtering logic is non-trivial — decoded body size limits, multipart part counts, per-part header counts, nesting depth, binary content in form bodies, extremely long field names — which is precisely why you want it delivered as a managed capability rather than hand-written rules.

ESA already ships the virtual patch — one switch, automatic blocking

Alibaba Cloud ESA has released managed-rule coverage for the PHP2Shell family, delivered through the built-in WAF managed rule set of every ESA site. In the ESA console the rules appear under the managed-rule categories; the virtual patch for the session.upload_progress exploitation path (CVE-2026-109618) ships as rule 901222 ("PHP Session.upload_prog…") in the Others category, alongside the companion coverage for CVE-2026-109619, with the action set to Block:

123

C267AF47_6563_43F5_B70B_D595A026A884

The ESA console showing the managed rule set for a site: the PHP2Shell virtual patch (rule 901222) sits in the "Others" managed-rule category with its action set to Block. There is nothing to write and nothing to tune.

The operational story is deliberately boring, and that is the point:

  1. Open the ESA console, select your site, and go to the WAF managed rules page.
  2. Make sure the managed rule set — including the Others category where these virtual patches live — is enabled, with the action set to Block.
  3. Done. From that moment on, requests matching the PHP2Shell exploit signatures are dropped at Alibaba Cloud's edge nodes, before they ever reach your PHP-FPM workers, mod_php processes, or containers — on every PoP, globally, immediately.

No custom rules, no regex authoring, no per-application tuning, and no agent to install on your origins. As Alibaba Cloud's security team refines the signatures or new exploit variants appear, the managed rules are updated centrally and every enabled site inherits the improvement automatically. And because enforcement happens at the edge, the malicious payloads are terminated close to their source: your origins never spend a CPU cycle parsing a weaponized multipart body.

The same managed rule set also carries broad coverage for the usual web-attack classes (SQL injection, XSS, command injection, webshells and more), so enabling it raises your baseline well beyond this single incident.

What you should do now

  • Patch PHP. Upgrade to 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, or apply vendor backports for 7.4–8.1. Virtual patching buys you time; only the fixed builds close the flaw. Restart workers after upgrading so no stale state survives.
  • If you are on ESA: verify the managed rule set is enabled with Block action, as shown above. This is a minutes-long change that closes the exposure window tonight.
  • Interim host hardening if you cannot patch or front the app immediately: set session.upload_progress.enabled = 0, disable fatal_error_backtraces on PHP 8.5, and review memory_limit together with external request-size limits — understanding these are stopgaps, not fixes.
  • Hunt for attempts: review WAF and access logs for oversized multipart POSTs, anomalous or binary form-field names, and bursts of requests hitting the same workers — the typical PHP2Shell noise.

PHP's ubiquity is what makes PHP2Shell dangerous, and it is exactly why edge-level, centrally managed protection matters. The vulnerabilities were disclosed yesterday; the defense in ESA has already been delivered. Turn it on, and let the edge absorb the storm while your patching program catches up.

References

WAF Security ESA CVE-2026-109618 PHP RCE
0 0 0
Share on

Read previous post:

Using ESA as a Front Door for Private OSS: STS Authentication, Cost Optimization, and Security

ESA Big Fan

7 posts | 1 followers

You may also like

Comments

ESA Big Fan

7 posts | 1 followers

Related Products

More Posts by ESA Big Fan

See All