Five hours before the patch: PHP2Shell on Nothreat digital twins

At about 08:40 UTC on 21 October a Nothreat CyberEcho digital twin at one of our customers received a short request. The twin stands on the customer's network as one more web server. The sender called itself php2shell-scan and posted a form field that has been part of PHP for years: PHP_SESSION_UPLOAD_PROGRESS. The Nothreat Platform does not take a sender's word for what it is. A name is easy to fake, and attackers fake names to mislead detection. So the platform set the label aside and looked at the request itself. The field had never reached a twin before, so the platform marked it as new and began counting every request that carried it. The request did not try to take the server over. It asked whether the server was the kind that could be taken over.

At that moment there was no patch, no advisory, no CVE record and no public detection rule, only the traffic. The existence of the two flaws and their CVE numbers had leaked the day before, on 20 October, and PHP had moved its security release forward by a day, to 14:00 UTC. The advisory naming the PHP feature the flaws go through was still five hours away. Whoever sent the morning request already knew where to look.

The flaw, briefly

PHP2Shell is two critical bugs, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 and both reachable without logging in. In short, an attacker can make PHP lose track of its own memory while it handles a request, and in some conditions run code on the server as the web worker. PHP's advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp) have the details, and the fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. One confirmed route for the second bug goes through session upload progress, a PHP feature that is on by default, needs no session_start() call, and powers upload progress bars. That is why the form field above shows up in the attacks.

The field itself is ordinary. A website with an upload progress bar sends it all the time. Seeing it proves nothing on its own. On 21 October it earned attention because of where it arrived, and how.

What the twins recorded

From the first request the platform was counting. The twins in this record run at Nothreat customers. Each customer chooses whether to share what its twins see; this record comes from those who do, and Crowd Immunity, the Nothreat Platform capability that pools that intelligence across the customer base, is where the pattern became visible. The count came from what the twins saw, not from any advisory, rule or outside feed. A count becomes a signal only when the evidence is strong: a request with enough pieces the platform has never seen, or the same new piece arriving from several networks. Twins receive a steady stream of odd requests, and a signal for every one of them would bury the ones that matter. This is how the evidence built up. Times are rounded.

The wave covered the morning's requests too, from the first one on. The CVE numbers in the afternoon tool strings were not a secret: they had been public since the leak. The records themselves appeared only at 13:48 and 13:54.

How a platform catches an attack with no name

A signature asks one question: does this match something we know? Someone has to write that signature first, after the attack is understood, and then it has to reach every sensor. On 21 October nobody had, for us or for most defenders. The lag is built into the method, and a flaw that leaks before its patch spends every unpatched hour inside it. A preemptive platform built on digital twins asks three other questions, none of which needs the attack to have a name.

Who sends requests to a twin? A digital twin is a decoy shaped as a real system and exposed like one, but it has no real users. Any interaction with a twin is, by definition, an attack. On a normal web server, this form field could be a customer uploading a photo. On a twin there is no customer. A sensor that sees hostile traffic and nothing else has one job left: to tell new from known. The twins in this set do not run PHP, so there was nothing on them for the flaw to break. They answered, recorded, and kept counting.

Have we seen this before? The Nothreat Platform learns the vocabulary of the requests that reach its twins: paths, field names, small fragments inside them. It learns continuously, from the traffic itself, so the vocabulary is current without anyone updating it. At about 08:40 the field name was new. At about 12:30 a request arrived with more pieces the platform had never seen: the scanner's own tag and random strings it had made up for this run. That was enough for the first rule to fire. The request even carried headers announcing a research purpose. Someone had already turned the flaw into a scanning template and was running it across the internet, hours before the advisory named the feature it probes.

Is it coming from more than one place? One strange request is a curiosity. The same strange token arriving from unrelated networks within hours is a campaign. At about 13:00 the platform joined requests from four hosting networks, pooled across customers through Crowd Immunity, into one event and rated it a potential zero-day. The rating held: it confirmed the signal from about 12:30, and both came before the patch existed.

There was one more sign, and it is worth a line because it describes a limit of a different method. Many of the addresses sending these requests were unknown to the third-party threat intelligence the platform checks. They were new, so a reputation list had nothing to say about them yet. A reputation list, like a signature, describes attacks someone has already seen.

A customer gets more than the record. Each twin reports into the Nothreat Platform, which shows the event in Investigate with the addresses, the requests and the twins they reached. Where Nothreat ThreatShield is deployed, the addresses seen on the twins are blocked automatically on the customer's existing network infrastructure, so the same traffic does not reach a real PHP server, and through Crowd Immunity the same intelligence reaches the other customers who share it. None of that depends on the flaw having a name.

From scan to exploit: the tools tell the story

Over the next days the senders' tools changed, and their names show how.

• Day one, 21 October: checks. Scanners asked whether a server was vulnerable and said so in their names. Several dozen requests from about twenty addresses, reaching under ten twins.
• Day two, 22 October: exploits. One tool called itself php2shell-exploit and sent about three quarters of the day's requests. The day's total more than doubled.
• Day three, 23 October: commodity. The loudest tool was a generic Python HTTP library. The method had been copied into ordinary scripts.
• Day four, 24 October, partial: more requests than on any day before, from under ten addresses, reaching more than three times as many twins as on day one. Fewer senders, more targets.

What this does and does not show

The record is from Nothreat CyberEcho digital twins at customers who share intelligence through Crowd Immunity, which the field had reached on a few dozen twins by 24 October. It is one vantage point, not a census of the internet. We cannot say how many real PHP servers received the same requests, or how many were exploited.

We cannot tell researchers from attackers by their headers, and neither can a production server. Some of the senders announced a research purpose; some named a bug bounty. The twins treated their requests like any other, because a twin cannot verify intent and has no reason to try.

The five hours in the title run from the first request carrying the field to the patch. The first rule fired about an hour and a half before the patch, and the wave rule about an hour before. We give all three numbers because they measure different things: when the evidence existed, when it was strong enough to act on alone, and when it was confirmed from several sources.

We did not know about PHP2Shell before 21 October. The platform had no rule for it, and nobody added one during the day. Everything in the table came from rules that exist for any flaw: new content, new senders, the same new token from unrelated networks.

The record came first

For most of 21 October the flaw was known to attackers and to the vendor, the patch was not out, and defenders were still writing rules. Inside that gap, Nothreat CyberEcho digital twins recorded who was probing, from where and with what tools. When the probing turned into a campaign, the Nothreat Platform turned it into a single event, before the fix existed. That is what the preemptive layer adds for a leaked flaw: the evidence is there before the patch, and the rules that produced it were written before anyone had heard of PHP2Shell.

Nothreat CyberEcho digital twins are part of the Nothreat Platform. See how they work on the CyberEcho page, or book a demo.

Sources: CVE-2026-109618 and CVE-2026-109619 (CVE Program) · PHP security advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp · PHP news · NCSC: Critical security issue affecting PHP · Canadian Centre for Cyber Security, AL26-026 · Nothreat Platform data, 21 to 24 October 2026. Times in UTC, rounded.