PHP Site AuditIncident response
If you suspect a PHP website was compromised: first response steps
If you see evidence that a PHP site may have been compromised, involve the hosting or security team, preserve relevant logs and system evidence, contain affected services under your incident plan, and patch the PHP runtime. A vulnerable version does not by itself prove compromise, and a patch does not prove that no earlier compromise occurred.
Keep observations separate from conclusions
Record what triggered concern, when it appeared, which domain or server is involved, and what data supports it. Examples include unexpected account activity, new files, unusual processes reported by a host, or suspicious log entries. Do not label a system compromised from a version banner alone; it reports a possible runtime clue rather than evidence of attacker activity.
PHP confirmed that CVE-2026-109618 and CVE-2026-109619 can allow unauthenticated code execution in vulnerable web-serving installations. The PHP advisory establishes the software risk. It does not establish that any specific business was attacked or breached.
Preserve and contain with your incident team
Notify the hosting provider and the person responsible for security. Preserve relevant server, web, PHP, authentication, application, and cloud logs according to your incident plan before routine retention overwrites them. Record timestamps and changes made. Avoid ad hoc cleanup that destroys evidence.
If containment is needed, coordinate it with the business owner so customer and operational impact is understood. PHP's advisory says update is the complete solution to PHP2Shell; apply a provider-confirmed fixed build as soon as practical. If safe patching is delayed, use the provider's incident-response process to choose a containment step. Do not describe temporary measures as a complete fix.
Assess impact before making external claims
Have a qualified responder examine the evidence, determine affected systems and data, and advise on recovery. Restore from trusted sources where needed, rotate credentials if the investigation indicates exposure, and monitor after recovery. Notification requirements depend on the data, jurisdiction, contracts, and investigation; consult counsel and applicable regulators rather than relying on a generic web guide.
Tell customers or partners only what is confirmed, what actions are underway, and when you will update them. Keep the timeline and supporting evidence for follow-up review.
Common questions
Should I patch before investigating?
Coordinate urgent patching with the host and security lead while preserving relevant logs needed to assess earlier access.
Does patching prove the site was never compromised?
No. It addresses future exposure, not what may have happened before the deployment.
When should credentials be rotated?
Follow the incident plan and evidence, using known-clean devices and approved procedures rather than assuming every alert proves theft.