What happened
Delft Threat Intelligence Lab at Delft University of Technology has published a live view of activity targeting CVE-2026-109618 and CVE-2026-109619, collectively labelled PHP2Shell. The tracker says it draws on honeypots and a network telescope, excludes the lab’s own test traffic, replaces sensor addresses with a placeholder, uses UTC throughout, and refreshes every five minutes. Its displayed data covers activity since 20 October; the recorded exploitation-request window runs from 21 October 08:37:17 UTC to 28 October 08:58:43 UTC.
At the stated update time, the lab counted 72,343 exploitation requests from 659 source IPs, spanning 305 autonomous systems and 73 countries. It says 174 source IPs sent code or a dropper. The tracker logged 2,725 sensor addresses hit and 743 distinct multipart boundaries. Its busiest reported hour was 26 October at 14:00 UTC, when it saw 8,179 requests. These are measurements of traffic reaching Delft’s instrumentation, not a count of vulnerable PHP deployments or a census of the internet.
The source separates attempts by the furthest stage observed. It lists 52,720 probe requests, 10,509 code-execution requests, 4,465 overload requests, and 4,649 dropper requests. The technique table includes operating-system commands, PHP code placed in a filename or progress field, session-deserialization gadgets, forged structures associated with the use-after-free path, and several resource-exhaustion forms. The first request resembling PHP2Shell reached the network telescope at 08:37:17 UTC on 21 October. The first high-interaction-honeypot request followed at 13:00:12 UTC, while the first observed OS command and PHP code in a filename appeared shortly after.
The tracker’s public timeline places the fixed PHP releases at 21 October 14:00 UTC: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. It also records two IPs making 49 requests before those fixed releases. After release, the lab observed the first wget or curl dropper request at 14:25:31 UTC. The page lists download endpoints as indicators to block rather than destinations to visit, and describes recovered payload categories including Mirai-derived components and a Nim backdoor. The practical point is not that every request succeeds; it is that the observed campaign includes steps beyond simple fingerprinting.
What the archive adds
This is a new fact in a known story. Earlier notes established that PHP2Shell was confirmed as working in the wild and that 93.6% of measurable PHP hosts remained unpatched five days after fixes. Delft adds a larger, continuously updated measurement of request volume, sources, and observed execution and dropper stages.
Trend signal
No supplied New Runtime pattern genuinely fits this event. This is evidence of conventional internet-wide exploitation and patch lag, rather than evidence about a durable change in agent architecture, protocols, or AI operating models.
Why now
The source’s timeline explains the speed of the response cycle: information about the vulnerabilities circulated during a leak window, PHP moved its release forward, and exploitation-looking traffic was already visible before fixed versions shipped. The tracker now supplies a running measure of what followed the emergency release rather than a one-time account of the disclosure.
Connections to other events
The earlier PHP2Shell Field Note reported successful in-the-wild remote code execution with memory disclosure and a matching exploit payload. Delft’s later count does not independently establish compromise of any particular server, but it connects that proof of exploitability to sustained traffic containing code-execution and downloader behavior. The archive’s patch-lag note supplies the complementary exposure condition: many measurable instances were still not updated after the fixes became available.
Why it matters
Teams building AI products often inherit PHP services through customer portals, content systems, legacy APIs, WordPress, Drupal, Joomla, or adjacent operational tooling. The important engineering lesson is not to treat a critical dependency patch as a ticket that ends when a version is changed. An active-exploitation event needs an evidence loop: determine which deployments used affected versions, verify the running version rather than the intended image, examine relevant logs, and preserve a clear owner for exceptions and remediation.
The Delft data also separates probes from later steps. That distinction can help teams prioritize investigation: high-volume scanning alone is not evidence of compromise, but shell execution, unexpected child processes, downloads initiated by PHP, or suspicious multipart request patterns warrant a focused review. Security work here is operational verification, not simply vulnerability-intelligence consumption.
What happens next
- Organizations with externally reachable, unpatched PHP instances will continue to face automated probing and payload-delivery attempts. (3 months, 85%). Watch for: sustained tracker counts and fresh dropper indicators.
- Defenders will increasingly distinguish scan volume from execution-stage telemetry in incident triage. (3 months, 65%). Watch for: guidance focused on process, download, and application-log evidence.
Limits and uncertainty
The source observes Delft’s honeypots and telescope, not all PHP servers or all attacker infrastructure. Source IP counts can be distorted by shared infrastructure, rotation, spoofing constraints, or repeat traffic; request counts do not equal successful compromises. The lab’s stage labels describe what its sensors observed, and the page does not establish the success rate of every technique against production targets. It also does not provide a population-level patch rate, victim count, or attribution for the traffic. Payload descriptions and listed indicators are useful defensive leads, not proof that every actor used the same malware or objective.
Skill to build now
This week, make a short verification runbook for internet-facing PHP services. Inventory the deployed PHP version from the runtime, compare it with the fixed versions named by the PHP release, identify services that cannot be upgraded immediately, and assign an explicit compensating-control owner. Then test whether logging can surface a PHP worker spawning a shell or initiating an unexpected outbound download. Keep the result as a dated, reviewable artifact rather than a verbal confirmation that patching is complete.
Reader takeaway
PHP2Shell activity is measurable at a scale that includes more than reconnaissance: Delft recorded code-execution and downloader-stage requests after the emergency fixes. If a product depends on exposed PHP, verify the deployed release and investigate meaningful execution signals; do not infer safety from the absence of a single scan alert.
Open question
How many of the observed code-execution and dropper requests succeeded against real, exposed PHP deployments, and how quickly will public patch-lag measurements decline?