PHP Site AuditIncident response
My PHP site looks normal. Could it still be vulnerable or compromised?
Yes. A site can return normal pages while running an unpatched PHP package, and an earlier intrusion may leave no obvious visual change. Appearance is not package evidence or forensic evidence. Confirm the runtime with the host; investigate compromise separately if logs or other indicators warrant it.
A working homepage answers only a narrow question
A successful page load shows that a response was returned from the path and time you tested. It does not reveal the PHP package, patch level, worker configuration, hidden routes, or what happened in an earlier session. An attacker who gains server access may choose not to alter the visible page, and ordinary outages or errors can also make a legitimate site look suspicious.
PHP says the 2026 flaws can permit unauthenticated remote code execution. That is a technical capability of affected installations, not a statement that every installation has been exploited. Keep three questions separate: is the runtime fixed; was suspicious activity observed; is there evidence of unauthorized access or persistence?
How to check the patch question
Ask the hosting provider or server administrator to identify the PHP build serving each public hostname, the package vendor, the advisory or backport covering CVE-2026-109618 and CVE-2026-109619, and when the workers were restarted. PHP's advisory and the related fixed-version guide provide the current upstream release list. Vendor builds can have different numbering, so request package-level confirmation.
A content management system dashboard, a public response header, or the result of php -v on your laptop may describe something other than the web runtime. None alone can prove the package is patched. Preserve the provider's written reply and correlate it with deployment records if the site is managed by your own team.
How to investigate a possible incident
If you see credible indicators such as unknown administrator accounts, unexpected files, unfamiliar outbound traffic or anomalous authentication events, preserve relevant logs and system snapshots before making changes that might erase evidence. Involve your hosting provider and incident-response lead; use a known-clean device for credential resets and follow your organization's response plan. The right steps depend on the platform and the evidence available.
Patch promptly, but do not treat patching as a forensic conclusion. A fixed runtime closes the known software issue going forward; it cannot tell whether the server was accessed before the update. Likewise, reinstalling or deleting files without preserving evidence can make it harder to determine scope. Rotate credentials or notify affected parties based on the investigation and applicable obligations, not on a banner or headline alone.
Common questions
Does no visible defacement mean no compromise?
No. Many incidents do not change the public page; consult logs and system evidence.
Does an old banner prove exploitation?
No. It may be stale, customized or reflect a different runtime. It is a lead to investigate, not proof of access.
Can a public assessment certify that nothing happened?
No. It samples public responses and cannot inspect historical logs, server files or private activity.