Last checked: · Source review; separate from content updates.
Short answer: An updated PHP version does not establish whether your server was compromised earlier. Review historical process activity, files and logs with your administrator. Amazon's observations support investigating activity before public disclosure.
Start with evidence, not a clean version result
The following is a suggested review workflow, not a PHP2Shell detection signature. The Canadian Cyber Centre recommends examining logs and unexpected processes, files, accounts and outbound connections. Follow your organization's response plan; NIST SP 800-61 Rev. 3 provides the broader response framework.
- Record the affected sites, package revisions and known update and restart times. Ask the host to retain relevant historical evidence before routine cleanup removes it.
- Review web, application, authentication and endpoint logs together. Correlate suspicious activity with process and file changes; one error or changed file is not enough to attribute an incident.
- Investigate unexpected execution or file modifications associated with PHP or web services. Have an administrator compare changes against deployment records and expected application behavior.
- Escalate credible signs to your host or incident responder. Agree containment, evidence preservation, credential replacement and recovery steps before treating a package update as incident closure.
Choose the investigation window
Amazon reports a honeypot attempt dated and recommends investigation from at least that date. This is a reported observation, not proof of compromise of your server. Amazon Threat Intelligence report.
Singapore CSA reports exploitation attempts in its updated alert. Different advisories describe observations at different times; keep the attribution and date with the report. CSA alert · Timeline.
If you have limited access
Ask the host to review the website's actual runtime and historical activity, preserve available logs, and explain what evidence supports its conclusion. Do not send credentials or private logs to this site's version checker. Use the WordPress hosting or cPanel guide to request the package update, and keep incident response open separately.
Common questions
Does patching PHP remove an existing compromise?
A package fix is not an incident investigation. Review historical activity and follow your response plan before declaring recovery.
Sources: Amazon Threat Intelligence: pre-disclosure observations · NIST SP 800-61 Rev. 3: incident response
How far back should I investigate?
Amazon reports an attempt dated 2026-10-17 and recommends investigating from at least that date. Treat this as a starting point, not proof of when your own exposure began.
Sources: Amazon Threat Intelligence: pre-disclosure observations
Do unexpected files prove PHP2Shell was used?
No. Suspicious changes warrant investigation, but attributing them to a particular vulnerability requires evidence. Correlate files, process activity and logs rather than relying on one symptom.
Sources: Canadian Cyber Centre: AL26-026
What if I have no server logs or root access?
Contact your host or security team for an investigation. Ask it to preserve relevant logs and review the affected runtime, accounts, processes and file changes. A clean checker result cannot replace that work.
Sources: Canadian Cyber Centre: AL26-026 · NIST SP 800-61 Rev. 3: incident response