Cybersecurity researchers have observed PHP2Shell exploitation attempts appearing in the wild almost immediately following the release of security fixes, highlighting the importance of prompt vulnerability remediation.
Research published by Cato Networks provides an interesting timeline of activity targeting the PHP2Shell vulnerability.
Cato Networks observed no external requests matching the PHP2Shell attack pattern between 17 and 20 October. However, on 21 October, the same day PHP released its security fixes, the first external scanning and invalid proof-of-concept (PoC) attempts appeared.
Approximately 72% of all PHP2Shell-pattern requests in Cato’s sample occurred on 21 October, while around two-thirds of the observed attack sources first appeared that day.

PHP2Shell activity targeting New Zealand organisations
We have also identified some of the IP addresses associated with this activity making attempts against New Zealand organisations between midday 22 October NZST and midday 23 October NZST.

While not every scanning attempt necessarily represents a successful exploitation attempt, the timing provides a useful example of how quickly threat actors and automated scanning infrastructure can begin probing for newly disclosed vulnerabilities.
For New Zealand security and operational teams, this is a good real-world example to share when reinforcing the importance of timely patching. IF you can observe it in your security logs it would be a good security awareness item for your management reports.
The window between a vulnerability becoming public and opportunistic scanning activity beginning can be extremely short. Waiting for the next scheduled patching cycle may leave internet-facing systems exposed to unnecessary risk.
PHP2Shell indicators of compromise (IOCs)
The following IP addresses have been associated with the observed PHP2Shell-pattern activity and subsequent attempts against New Zealand organisations.
Observed IP addresses:
103[.]216[.]220[.]92
31[.]223[.]184[.]166
37[.]19[.]200[.]5
134[.]209[.]159[.]64
95[.]217[.]98[.]37
103[.]114[.]163[.]188
172[.]234[.]200[.]18
85[.]11[.]167[.]243
143[.]246[.]223[.]124
38[.]60[.]206[.]217
176[.]124[.]32[.]170
185[.]225[.]191[.]232
2[.]27[.]248[.]209
147[.]182[.]234[.]126
31[.]56[.]53[.]223
104[.]248[.]145[.]184
49[.]43[.]128[.]164
3[.]144[.]181[.]153
77[.]90[.]185[.]20
18[.]225[.]170[.]231
Organisations should consider reviewing firewall, web server and application logs for connections from these addresses, particularly where PHP-based applications are exposed to the internet.
The takeaway: Patch promptly, particularly for internet-facing vulnerabilities. Attackers do not necessarily wait for organisations to complete their normal vulnerability management cycles.