Suspect Your Website Was Hacked? + Free PHP and WordPress Incident Recovery Checklist
Unexpected redirects, unknown administrators or a hosting suspension should prompt evidence preservation and contact with your maintainer. Updating PHP alone does not establish that backdoors are removed or that data was not exposed. This article provides a general response and handover checklist. Updated: 2 November 2026.
Separate suspicion, evidence and cause
Redirects, unauthorised accounts, malicious content and supplier warnings warrant investigation. They do not establish that a particular PHP vulnerability caused the incident. Record observed facts, sources and times, distinguishing unconfirmed concerns from verified findings. A failure immediately after an update can also be a compatibility issue requiring a different investigation.
Stage one: preserve evidence and limit impact
□ 1. Record the discovery time, timezone, URL, symptoms, screenshots and recent changes. Expected: a traceable timeline; ask the maintainer if evidence cannot be preserved.
□ 2. Contact the host, website maintainer and business owner and nominate an incident coordinator. Expected: a coordinator and contact plan; involve incident specialists immediately for sensitive data.
□ 3. Have technical staff preserve logs, files and database snapshots with restricted access. Retain unknown files before deciding how to clean up. Expected: restricted evidence copies; ask the host if access is missing or evidence may be lost.
□ 4. Limit affected services or transactions according to the risk and provide a safe contact route so other workflows do not increase the impact. Expected: scoped restrictions and a safe contact route; specialists should decide isolation for payments or personal data.
Stage two: investigate entry and continuing access
□ 5. Examine administrators, logins, file changes, scheduled jobs, plugins and settings for unauthorised activity. Expected: a documented activity review; escalate unknown accounts or persistent access to incident specialists.
□ 6. Assess affected systems and data. Where logs are insufficient, retain that uncertainty rather than claiming there was no exposure. Expected: known impact and explicit unknowns; insufficient logs or customer data need professional investigation.
□ 7. Remediate the entry point and remove malicious code or rebuild from trusted sources; deleting the visible malicious page alone is insufficient. Expected: evidence of entry-point remediation and cleanup or rebuilding; uncertain backdoor removal needs specialists.
□ 8. From a trusted device, rotate relevant credentials and keys and revoke sessions as appropriate. Avoid entering fresh credentials into an environment that remains compromised. Expected: a credential and session-revocation record; specialists should sequence changes if trust is uncertain.
Free resource: Website Incident and Recovery Checklist
The editable Word resource contains twelve staged checks, an incident timeline, evidence locations, impact and ownership fields and recovery sign-off. It supports handover between your team and specialists. Links arrive by email; email, intended use and an initially unchecked subscription choice for occasional Allua marketing updates are required, with unsubscribe at any time.
Stage three: validate recovery before reopening
□ 9. Select an appropriate trusted backup or rebuilt version and compare its date with the suspected compromise timeline. The newest backup is not necessarily clean. Expected: backup trust and consistency checks; have a professional assess restoration if the timeline is unclear.
□ 10. Inspect form recipients, payment settings, DNS, redirects, administrators and integration keys for unauthorised changes. Expected: authorised settings confirmed individually; escalate misrouting or payment changes to security and business owners.
□ 11. Test visitor, login, enquiry and transaction journeys, checking notifications and stored records and verifying that remediation is applied. Expected: journey records, notifications and remediation evidence; return failures to maintainers before reopening.
□ 12. Document the reopening decision, observation period and escalation owner. Obtain appropriate professional advice on any notification, contractual or data-protection obligations. Expected: named reopening approval and monitoring plan; notification, contract and data-protection questions need appropriate professionals.
What belongs in an incident record?
For each event, record the time and timezone, observed fact, evidence location, operator, action and result. Illustrative example: 14:20 HKT, a customer reports a redirect; 14:28, the maintainer confirms an unauthorised redirect on one route; 14:35, the host preserves logs. This is a recording format, not evidence of an attack source or data exposure.
Frequently asked questions
Q: Can a clean scan close the incident?
A: Not alone. Entry points, continuing access, permissions and business acceptance still require attention.
Q: Does patching PHP make everything safe?
A: A patch addresses specific vulnerabilities; it does not automatically remove backdoors or revoke stolen credentials.
Q: Should we immediately restore a backup?
A: A professional should assess evidence preservation, backup trust, data consistency and business impact first.
Q: When should we involve incident-response specialists?
A: Escalate early for customer data, payment systems, repeated compromise, multiple affected systems or uncertainty about cleanup coverage.
Need help defining the maintenance handover?
For an Allua website-maintenance and recovery-acceptance enquiry, provide the URL, host, symptoms, time and existing maintenance arrangements. For an active compromise or sensitive data, also contact specialists experienced in incident response. Do not upload confidential logs through a public form. Enquiries: https://www.alluatech.com/contact-us
Official references
WordPress compromised-site guidance: https://wordpress.org/documentation/article/faq-my-site-was-hacked/
PHP security announcements: https://www.php.net/
WordPress debugging: https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
Disclaimer
This article is based on general scenarios and information available as of the stated update date. It is for general information only and does not replace a professional assessment of your individual system. Hosting environments, PHP versions, configurations, plugins and integrations vary. Before updating software, changing settings, restoring a system or taking other action, consult a professional web developer or hosting provider to assess your specific circumstances and determine the appropriate action. If you suspect a compromise, also seek help from a professional experienced in cybersecurity incident response.
Comments