29 Oct: 72,000 PHP2Shell requests logged

What the tracker counted

TU Delft IntelliLab’s live dashboard recorded 72,679 PHP2Shell-related requests from 664 source IPs across 309 autonomous systems and 73 countries. The observation window runs from 21 October 08:37 UTC to 29 October 01:16 UTC; the figures quoted here were read at 01:27 UTC on 29 October.

That is a more granular measurement than the “millions of attempts” summaries published earlier, but it measures a different thing. The Delft figures are requests recorded by the tracker, not a count of compromised servers.

By 30 October 11:12 UTC, the running totals had reached 76,153 requests from 680 IPs across 317 autonomous systems and 73 countries; 177 IPs had sent code or a dropper. The observation window closed at 11:11 UTC. The growth is still request volume, not a victim count.

Where the requests stopped

The dashboard classifies traffic by the furthest stage it observed:

• 52,990 probes from 553 IPs
• 10,510 code-execution requests from 148 IPs
• 4,523 overload requests from 132 IPs
• 4,656 dropper requests from 50 IPs

It also says 176 IPs sent code or a dropper. Those categories overlap with the stage totals, so they should not be added together. Peak activity was 8,179 requests in the hour beginning 26 October 14:00 UTC.

A request that reaches a code-execution or dropper stage is stronger evidence than a probe, but it is still evidence about attack traffic. It does not establish that the target was a production system, that the exploit succeeded, or that any data was taken.

Patch progress is uneven

LACNIC published a regional analysis on 28 October using Censys data as of 26 October. In Latin America and the Caribbean, 12.8% of exposed PHP services with identifiable versions were running a patched release, compared with 25.1% globally. The analysis covered 21 countries.

The comparison has a hard limit: the unpatched share includes servers on PHP branches that no longer receive security fixes. LACNIC says Censys does not break those out by country, so it is impossible to determine how much of the remaining 87% can be fixed by patching and how much requires migration to a supported branch.

A separate Korean survey reported by Boannews on 29 October gives a more granular but still partial picture. Using Shodan, it counted 1,773 of about 6,500 patch-eligible servers running PHP 8.2–8.5 as patched (27.3%). Across all Korean PHP servers, including end-of-life branches, it put the rate at about 5.5%. It estimated that about 80% of Korean PHP servers run PHP 8.1 or older, roughly 23,000–25,000 hosts that need a version upgrade rather than a patch.

The survey ran ten queries and excluded servers whose PHP version could not be identified, so the authors say the true remediation rate may be slightly higher. It is a media-run survey, not a government count, and it does not identify specific victims.

What this does and does not establish

CISA’s KEV catalog version 2026.10.29 still lists both PHP2Shell CVEs, added on 26 October. The 29 October due date has passed. The KEV entry is a determination that the flaws have been exploited; it is not a victim count.

What the new data adds is scale and geography, not a confirmed breach count. Patch uptake is measurable and uneven. Attack traffic is measurable and uneven. Neither measurement tells you whether a particular organisation was compromised.

The operational advice is unchanged. Patch PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and restart every worker. Inventory embedded PHP in appliances and hosted products. If compromise is possible, preserve logs before rebuilding and review web, process, authentication and directory activity.

The verification guide covers runtime checks. The mitigation guide covers the sequence when patching cannot happen immediately. The dossier keeps the CVE scope and source links together.