PHP security report
Early PHP2Shell traffic: scanning, failed attempts and investigation clues
Security companies recorded PHP2Shell probes before PHP’s October 21 release and further attempts afterward. Their reports help administrators decide which retained records to examine. A request reaching a decoy, a working laboratory demonstration and a confirmed compromise of a customer server are different observations.
What the sensors recorded
A honeypot is a decoy system that records traffic for researchers. The times below come from separate companies’ reports, all checked on October 23. They do not describe one continuous view of the internet.
Scroll sideways to see all columns.
| Date and time | Reported observation | Source |
|---|---|---|
| October 17 | PHP2Shell attempt in MadPot; success on real systems unresolved. | Amazon |
| October 21, 08:00 | First exploit-related requests reached its sensors. | Coalition |
| October 21, 08:37 | Initial probe in its published timeline; the same source reached 188 decoys in total. | VulnCheck |
| October 21, 12:00–13:00 | 3,839 requests for PHP information pages, against roughly 100 in a typical hour. | Coalition |
| October 21, 16:05 | First requests matching the out-of-memory exploit’s general shape. | ELLIO |
| October 21, 17:22–17:24 | An attempted web-shell deployment failed; follow-up reads returned 404. | VulnCheck |
PHP’s PHP 8.3.36 announcement is timestamped 14:00:57 UTC on October 21. The companies’ earlier observations should therefore be considered when choosing a period for an incident review. The separate Amazon report explains the limits of its October 17 attribution.
Public PHP information pages drew attention
Coalition’s reconnaissance count concerns pages that expose PHP’s version and settings. Removing unnecessary public diagnostic pages reduces the configuration details available to outsiders. It also avoids giving away information unrelated to this incident, such as enabled extensions and server paths.
Removing a diagnostic page does not change the installed PHP package. Record that task separately from updating PHP, restarting affected services and confirming the build used by the website.
Keep the reported outcome beside the attempt
VulnCheck’s failed attempt is evidence of hostile intent and a particular failed sequence. It is not a confirmed victim. ELLIO’s analysis likewise distinguishes payload intent from whether the payload has the structure needed to execute successfully.
Sophos’s October 22 correction is a useful example of the distinction: it revised an earlier success claim to scanning and failed attempts in the customer telemetry it examined. These reports should retain their individual dates and limits as investigations continue.
Four tasks for the administrator
- Install and verify the security update. Use your supplier’s complete package revision, restart affected PHP services and confirm the build handling web requests. Keep a record of when the fixed service began running.
- Remove unnecessary public diagnostic pages. Review the site’s exposed administration and test interfaces while keeping required access available to authorized staff.
- Preserve and examine evidence. JPCERT/CC recommends checking unusual requests, session-cookie responses, worker behavior, processes, connections and file changes. Preserve relevant logs if compromise is suspected.
- Review potentially exposed secrets. Wiz demonstrated access to PHP process memory, which can hold credentials. An incident response should identify which secrets PHP could access and replace those found or reasonably suspected to be exposed.
An HTTP 200 response can still need investigation
Datadog’s refined laboratory demonstration returned HTTP 200, normally a successful web response, and left the same Apache worker running. A review limited to error codes or crashes would therefore miss that demonstrated behavior.
JPCERT/CC also cautions that different attack paths and logging settings can leave different traces, including no retained trace. Report the records examined and their gaps rather than claiming a server was never compromised.
Check the additional October 23 advice
PHP’s October 23 notice adds session-upload-progress guidance for CVE-2026-115560. Have the administrator review its configuration advice alongside the original package fixes.
Sources and scope
The timeline uses company reports of their own observations. JPCERT/CC supplies investigation guidance, summarized from its Japanese advisory; PHP supplies release and configuration notices.
Next: follow the PHP2Shell check-and-verify guide to confirm the running update and identify records that need further review.