PHP Site AuditBasics
Can a PHP vulnerability scan prove that a site was hacked?
No. A public scan may observe response behavior or a possible technology clue, but a vulnerability finding is not proof that anyone exploited it. A clean scan is not proof that no compromise occurred. Incident conclusions require evidence such as server, application, account, and provider logs reviewed by the responsible team.
Three different statements
‘The site may run a vulnerable PHP build’ is a vulnerability question. It requires reliable identification of the runtime and its package or vendor backport. A public version header can be a clue, but it does not prove the loaded build or patch state.
‘Someone attempted an attack’ is a traffic question. An HTTP request in an edge or origin log may match a pattern, but it may have been blocked, failed, or never reached PHP. ‘The site was compromised’ is a stronger incident conclusion: it needs evidence of unauthorized execution, access, persistence, data exposure, or another confirmed impact.
Before sharing evidence publicly, remove session IDs, authorization headers, email addresses, customer identifiers, and other sensitive data from screenshots or log extracts. Give the unredacted records only to the authorized incident team through its approved channel. Security reporting should be useful enough to investigate without turning the report itself into another exposure of customer or account information.
What an external scan can see
A public website assessment can observe selected HTTP responses, TLS details, headers, cookies, and technology clues from sampled pages. PHP Site Audit's public assessment is bounded to up to 100 same-host HTML pages, a shared 140-request budget, and 90 seconds. It does not exploit the site, log in, inspect source code, read server packages, view private runtime state, or establish what happened in the past.
That scope can help an owner decide what to ask next. A warning can prompt a runtime confirmation request; no warning can mean only that the sampled responses revealed no signal. Neither is a forensic finding.
What incident evidence may help
The hosting or security team can correlate origin access logs, WAF events, PHP and web-server error logs, authentication events, file-integrity records, deployment history, endpoint alerts, backups, and account activity. Exact evidence depends on architecture and retention. Ask the operator to preserve relevant logs before they expire and document timestamps, time zones, and affected systems.
A block event is evidence of a request handled by a control, not necessarily successful exploitation. A request reaching the origin is not by itself proof of code execution. Conversely, no visible page change does not rule out access to a hidden route or data. A qualified incident responder can interpret correlated records.
Handle findings without overclaiming
If a scan raises a vulnerability concern, confirm the runtime with the provider and update it through the supported process. If independent compromise indicators exist, open an incident case, preserve logs and system evidence, and follow the organization's containment plan. Patching addresses future exposure; it does not erase the need to investigate possible prior access.
Careful update: ‘The public assessment observed X; the host is checking Y; we have not concluded whether exploitation occurred.’ Replace that wording only when evidence supports a more specific statement.
Preservation matters because some evidence is short-lived. Hosting access logs, edge events, container logs, and authentication records may rotate or expire under different policies. A site owner who has a credible incident concern should promptly ask the provider what records exist, how long they are retained, and how to preserve a relevant period. Do not alter files, wipe a server, or run cleanup utilities before the incident owner decides what evidence must be retained.
A scan report is still worth retaining as a lead. Save its scope, time zone, scanner identity, paths sampled, request behavior observed, and any explicit limitations. Then compare it with the hosting team's records. If no compromise evidence is found, phrase the conclusion narrowly: what was reviewed and what was not available. Avoid turning a limited review into a guarantee that no unauthorized access occurred.
Owner checklist
- Save scan name, timestamp, exact hostname, and observation.
- Confirm package status with the host.
- Preserve and review incident logs if there are credible indicators.
- Distinguish blocked attempts from successful access.
- State only what the evidence establishes.
Common questions
Does a critical scan result mean attackers got in?
No. It may describe a possible weakness or observed response. Successful exploitation needs separate evidence.
If the scan is clean, can I rule out a compromise?
No. External scans do not inspect historical logs, private services, server files, or account activity.
What should I give an incident responder?
The exact hostname, timestamp and timezone, scanner output, provider case number, relevant logs, and a clear separation of observations from assumptions.