Recover a Hacked WordPress Client Site at Scale

When one client gets hacked, the question your team should ask is not only “how do we clean this site” but “how many others share the same vulnerable plugin.” This playbook covers both the single-site recovery and the fleet-wide containment that keeps it from happening again.

The instinct is to start deleting suspicious files. Resist it. The first hour is about containment and evidence, because a hasty cleanup can destroy the forensic trail you need to find the entry point — which means you’ll clean the site and get reinfected within days.

1. Take the site offline or into maintenance mode to protect visitors and stop active data theft.
2. Snapshot the compromised state — files and database — before changing anything, for forensics.
3. Rotate all credentials: admin users, database, hosting, SFTP, and any API keys.
4. Check whether the same host account or shared credentials touch other client sites — assume lateral movement until proven otherwise.
5. Notify the client with facts: what you know, what you’re doing, and the expected timeline.

You can’t clean what you can’t see, and you can’t prevent reinfection until you know how they got in. Most WordPress compromises trace back to a vulnerable or nulled plugin or theme, weak admin credentials, or an out-of-date core. Work both ends: find the malicious code, and find the door it walked through.

• Compare core, plugin, and theme files against clean copies from the official repositories to spot injected code.
• Scan for common indicators: obfuscated PHP, base64-encoded payloads, unfamiliar admin users, and modified .htaccess or wp-config.php.
• Review access and server logs around the first sign of compromise to find the exploited endpoint.
• Check Google Search Console for security warnings and blacklist status so you know the external impact.

You have two recovery paths. Restoring from a known-good pre-infection backup is fastest and cleanest when you have one and the compromise is recent. Manual cleaning is necessary when the infection predates your backups or the site has changed too much to roll back. Often the right move is a hybrid: restore core and plugins from clean sources, keep the current database after scanning it, and re-merge legitimate recent content.

• Restore path: roll back to the last verified clean backup, then immediately patch the vulnerability that caused the breach — otherwise you restore the hole too.
• Clean path: replace core/plugins/themes with fresh official copies, remove injected code, delete rogue users and unknown files in uploads.
• Always: update everything to current versions, regenerate salts, and force a password reset for all users.
• Verify: rescan, confirm the site is clean, then request review to clear any search-engine blacklist.

This is exactly why a tested backup and rollback discipline pays off: a clean pre-update or pre-infection snapshot turns a multi-day cleanup into a controlled restore. Recovery is only as fast as your last verified backup.

How you communicate during a hack often matters more to the relationship than the cleanup itself. Clients don’t expect you to guarantee a site never gets attacked; they expect you to handle it calmly and keep them informed. Silence reads as incompetence even when your team is working flat out behind the scenes.

• Lead with facts, not blame. State what was compromised, what data may be affected, and what you’re doing about it.
• Set a realistic timeline and update against it, even if the update is “still working, next check-in at X.”
• Flag any data-breach obligations early — if customer data was exposed, the client may have notification duties under privacy law.
• Close with a hardening summary so the client sees the breach made their site stronger, not just patched.

After the site is clean and the entry point is closed, run a short post-incident review while it’s fresh. Document the vulnerability, the dwell time, the cleanup steps, and what would have caught it sooner. That record is what turns a painful incident into a permanent improvement to your security baseline — and it’s the raw material for the fleet-wide hardening below.

One hacked site is an incident; the same vulnerable plugin on twenty client sites is a crisis waiting its turn. The moment you know the entry point, the priority shifts from one site to the fleet. This is the part single-site malware guides never cover, and it’s where agencies either contain the damage or spend the next month firefighting.

• Inventory which other client sites run the same vulnerable plugin, theme, or core version.
• Patch or disable the affected component across all of them as a priority sweep.
• Run a security audit across the fleet to catch sites already compromised but not yet noticed.
• Harden the baseline: remove nulled plugins, enforce strong admin auth, and standardize the update cadence.

Doing this sweep by hand across 25 to 50 sites is slow, and slow is how reinfection wins. Running audits and remediation through a structured execution layer is what makes fleet-wide containment practical. WPOS is an AI-native operating system for WordPress — the independent system that runs WordPress through a structured execution layer, working across any host and any builder rather than locking you to one stack. Its application-layer operate capability today includes automated audits and ongoing content management, which is precisely the work of scanning the fleet, identifying exposed sites, and pushing remediation.

The scale that work runs at is concrete: 286 connected sites, more than 70 active users, and over 20,000 agent tool-executions per month across the fleet. To be precise on the seam, the deeper host-layer capabilities — self-healing infrastructure and automatic rollback at the server level — are on the roadmap, not delivered today. Containment still depends on your tested backups and a human-directed remediation process; the execution layer is what lets you run that process across the whole fleet at once. If you want to put that to work on your own sites, the WPOS beta is the way in, and you can review the supported tooling on the connectors page.