Threat Research / TR-2026-02

Patched in a day, latent for a decade

PHP2Shell is two critical, pre-authentication remote code execution flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619. They reach back to PHP 5.4 and sit beneath the application, so the application logs most teams rely on see very little. This analysis traces how the flaws surfaced, why the detection problem lives below the app layer, and what to hunt for when the vendor has no indicators to give you.

Published
Author
DetectionHub Threat Research
Coverage
August – October 2026
Classification
TLP:CLEAR, public
70%+

of websites run PHP, the layer these two flaws live inside

5.4 → 8.5.11

every PHP release across twelve years is affected by at least one

9.2

CVSS for both, pre-authentication, no user interaction

14:00 UTC

21 Oct 2026, when PHP shipped the fix a day early after the leak

01 · Executive summary

Five things the PHP2Shell disclosure changed

A flaw in the runtime behaves differently from a flaw in an app. Here is what that difference does to a defender's week.

F-01

The bug is in PHP, not in any one app

You cannot scope this to a product you chose to run. PHP is the runtime under a large share of the web, so the exposed surface is every PHP process you have, wherever it runs. Wiz showed unauthenticated code execution against stock WordPress, Drupal and Joomla images and noted that even a one-file application on an affected version can be hit.

F-02

The details leaked before the fix

The coordinated release was set for 22 October. On 20 October a write-up appeared on Hacker News and was pulled, a short exploitation clip was posted and pulled, and watchTowr confirmed the leak. PHP moved its release to 21 October at 14:00 UTC. The quiet gap defenders usually get between a fix and its details did not happen here.

F-03

It fires below the application, where few teams watch

The flaw triggers inside the interpreter while it parses the request, before your code runs. Your application sees a normal request and an error response, and so does your WAF in many setups. The evidence is a layer down: PHP fatals during request startup, workers dying on a signal, and the child processes a shell opens once execution lands.

F-04

End-of-life PHP has no clean fix

Supported branches are patched: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are off upstream support and get only minimal source backports for teams that can rebuild. A lot of regional hosting and a long list of network appliances run exactly those versions, so for them this stays open for months.

F-05

The sources already disagree on exploitation

Within a day, Cloudflare reported attack traffic with payloads mutating to dodge its rules, and watchTowr and Patchstack reported activity, Patchstack citing confirmed incidents. Huntress, the Dutch NCSC and the CISA KEV catalogue reported nothing confirmed in the same window. While a patch race is on, read 'no confirmed activity' as 'not yet seen', not 'safe'.

02 · Context

A flaw in the interpreter is harder to run down than a flaw in the app

Most vulnerabilities belong to a named product. You can look up the version and decide whether it is yours. A flaw in PHP does not sit still like that. PHP runs under a large part of the web, so the question stops being whether you run the affected software and becomes where, and the honest answer is usually: in more places than the asset list shows.

Both flaws are reachable without logging in, through a feature PHP enables by default: multipart upload handling and the session upload-progress mechanism. The attacker pushes the interpreter out of memory while it is still setting up the request, which leaves request data half-built, then leans on a later request that reuses the same worker while that half-built state is still trusted. The exact path changes with the PHP version and the server, and the research teams report it working on default settings.

What makes it slow to clean up afterwards is where it lands. Code runs as the web service account, so a foothold is useful straight away. The application barely executes, so its logs hold little. And PHP is baked into things no one manages as a web server, from content platforms to firewalls and routers, which is how the same flaw turns up on a box whose owner never thinks of it as PHP.

The exploit chain

How one request becomes a shell

  1. Malformed multipart POST

    pre-auth

    An over-long filename and the upload-progress field, sent chunked so the body runs past the configured limit.

  2. Memory exhausted mid-startup

    CVE-2026-109618

    The interpreter runs out of memory while still setting up the request, before any script runs.

  3. Half-built state is left behind

    The fatal skips the step that would finish or roll back that request data, so it stays in memory.

  4. The next request reuses the worker

    CVE-2026-109619

    It trusts the stale state still sitting there, which is the use-after-free.

  5. Code runs as the web service

    RCE

    A shell, a dropped web shell, or memory read straight out of the worker.

03 · The record

From a 2004 footnote to a broken embargo

The memory-limit problem is old. What changed in 2026 is that someone turned it into reliable, pre-auth code execution.

2004 – 2024

a known-hard corner of the interpreter
  1. 2004 to 2024 · the long warning

    The PHP memory-limit problem is old news

    Stefan Esser found the first remotely triggered PHP memory-limit bug in 2004 and held back the exploit. Bug #78876 followed in 2020. In 2024 OSTIF and Quarkslab flagged a related issue in a PHP audit, where exploitation was unproven and nothing was fixed. The research behind PHP2Shell names the shared pattern: the engine sets up state, does work that can fail, then commits, and a fatal error in the middle skips the commit and leaves something downstream trusting state that was never finished.

    20-year lineageKnown, unproven, unfixed

2026

discovery, disclosure and a broken embargo
  1. August 2026 · disclosure starts

    Two teams land on the same flaws

    Calif, going back over the old memory-limit research through OpenAI's Patch the Planet work, found several ways to reach code execution in early August. It reported the first to PHP on 11 August, shared a working proof of concept on 14 August, and saw it confirmed on 15 August, then reported a second bug on 21 August. Wiz reported a parallel finding to the PHP security team in late August. PHP acknowledged the reports in September and set a release date.

    CalifWizOpenAI Patch the Planet
  2. 20 October 2026 · the leak

    The embargo breaks a day early

    A Hacker News post saying the flaws were about to drop went up and came down, but the screenshots spread. A short exploitation clip was posted and pulled. watchTowr confirmed the leak and said everyone had been asked to hold until the Thursday. The coordinated window was gone.

    Pre-disclosure leak
  3. 21 October 2026 · 14:00 UTC

    PHP ships the fix ahead of schedule

    PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, a day early, and the Wiz and Calif write-ups went public with it. PHP's security team put out minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source. Distributions and LTS vendors had fixes early; Ubuntu shipped the same day, and appliance vendors including OPNsense and Cisco started posting advisories.

    8.5.12 / 8.4.27 / 8.3.36 / 8.2.35EOL backports: 7.4 / 8.0 / 8.1
  4. 21 October 2026 · hours later

    The in-the-wild story splits

    Cloudflare reported attack traffic within hours, with payloads changing to get past its rules, and watchTowr and Patchstack reported exploitation, Patchstack citing confirmed incidents. Huntress, the Dutch NCSC and the CISA KEV catalogue reported nothing confirmed in the same window. Public proof-of-concept code showed up fast, but the chains that match the real flaws were the ones held back or put behind a paywall.

    Conflicting reportsPartial public PoC

04 · Regional lens

Why the Gulf and Egypt are more exposed, not less

The published exploitation traffic so far clusters in Europe and North America, and it is tempting to read that as distance. It is not. PHP is the default of the shared and budget hosting that most regional businesses sit on, it is what the common content platforms are built from, and it runs inside a lot of the network gear deployed here. The end-of-life versions with no clean fix are the ones that budget hosting tends to run.

The regional difference is what it costs to find out late, and to find out from someone else.

For banks under the Central Bank of Egypt's rules, and for peers across the GCC under similar supervision, the board question is harder than the technical one. On what evidence do you conclude the exposure window went unused? A list of patched servers answers a smaller question, and only for the servers it knows about.