When a client site looks compromised, preserve logs and a copy of the files, limit further damage, restore from a known good backup, rotate every credential the site could reach, and tell the client early. Do not start by deleting things.
This is a general checklist built on guidance in the WordPress handbook. Your host may have its own procedure and may need to be involved, so contact them at the start.
The first hour
| Step | Action | Why |
|---|---|---|
| 1 | Tell the client and your internal lead | Decisions about downtime need an owner |
| 2 | Contact the host | They can help with isolation and server logs |
| 3 | Copy logs and a snapshot of the files and database | Evidence disappears when you clean up |
| 4 | Limit damage: maintenance page, or block access if needed | Stops visitors being harmed |
| 5 | Change credentials: hosting, database, CMS admins, repository tokens | Assume the old ones are known |
| 6 | Find the entry point | Fixing symptoms without the cause invites a repeat |
| 7 | Restore from a known good backup, then patch | Cleaning in place can miss files |
Why logs come first
The hardening guide says logs let you see what was done, when and from where, and that attackers leave traces in logs or the file system, such as new or modified files. It also notes that logs show the IP and time of actions even if they do not show a username. So copy them before anything changes.
Where attacks usually enter
The handbook says the most common attacks fall into two categories: crafted requests that exploit known flaws in outdated plugins and software, and brute force password guessing. Check both. Look at which plugins and themes were out of date, and review login attempts and recent changes to administrator accounts.
Restore carefully
Restoring from a backup helps only if the backup predates the compromise. The WordPress backup guidance suggests keeping several recent copies in different locations, which is what lets you pick an older clean one. Restore files first, then the database, then patch the entry point before reconnecting the site to the internet.
After the first hour
- Find new administrator users and remove those you do not recognise.
- Review recently modified files against your repository or a clean copy.
- Rotate secrets stored in the site: API keys, mail credentials, database passwords.
- Check whether personal data may have been exposed, and take advice on any duty to notify. That is a legal question that depends on the client and region.
- Write a short incident note: what happened, when, impact and what changed.
Close the gap
Add what you learned to the retainer: the missing update, the extra admin, the untested backup. The best use of an incident is a smaller next one.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory is matched to components in use; that is the check that tells you which sites to look at first.
Safeguard's free scan can check a project's dependencies, but it does not replace host level forensics.
Quick check
Should I delete the malicious files immediately?
Copy them and the logs first. Removing them before you understand the entry point can destroy evidence and let the attacker back in.
Do I have to tell the client?
Yes, early. Tell them what you know, what you do not yet know and when you will update them.
Sources
Last reviewed: 19 October 2026.
