Support
Support

Fix a hacked WordPress site: a step-by-step recovery plan

The moment you suspect a WordPress site is compromised, rotate every credential tied to it and take the site offline while you work. If you have a verified, malware-free backup, restoring to that is usually the fastest safe route back to normal; if you don’t, follow a structured clean-up rather than guessing. For anything client-facing, revenue-critical, or where you’re unsure of the entry point, bring in a specialist instead of improvising under pressure.

TL;DR:

  • Restoring from a verified, malware-free backup can be the fastest recovery method if the backup predates the attack and has been confirmed clean.
  • Containment measures include changing all credentials, taking the site offline, preserving evidence, and assigning a single response lead to prevent further exploitation.
  • Analyzing logs and assessing the severity of the breach helps determine whether a quick cleanup suffices or if specialist assistance is necessary for persistent or data-related compromises.
  • After cleaning, implementing authentication, updating all software, limiting permissions, and deploying firewalls are crucial to prevent the same intrusion from reoccurring.
  • Clear communication with clients, visitors, and legal authorities about the breach is essential, especially if personal data was involved, to comply with legal obligations and maintain trust.

Table of Contents

How do you contain a hacked WordPress site immediately?

The first hour after you spot a compromise decides how bad the next week gets. Attackers who see you scrambling will often widen access before you can lock them out, so the priority is speed paired with discipline. Rushing straight to a fix without containing the breach first is how the same vulnerability gets exploited twice in the same month.

Work through these actions in order, from a device you trust, not the compromised server itself:

  1. Change every password that touches the site — WordPress admin accounts, hosting control panel, SFTP/SSH, database, and the email account linked to the domain. Do this from a clean machine on a network you trust, never from a browser session that might already be logged.
  2. Take the site offline or into maintenance mode. If full downtime isn’t acceptable, restrict access by IP through your hosting control panel or a firewall rule rather than leaving the front end live for visitors and search crawlers.
  3. Preserve a full snapshot before you touch anything else — files, database, and server logs, copied somewhere separate from the live environment. NCSC’s guidance on recovering from a cyber incident is explicit that overwriting evidence before you’ve investigated is one of the most common reasons attacks recur.
  4. Assign one person to lead the response and agree who talks to hosting, who talks to the client, and who touches the server. Ad-hoc fixes from two people working in parallel are how legitimate changes get mistaken for attacker activity, or vice versa.
  5. Revoke API keys and third-party integration tokens — payment gateways, email marketing plugins, CRM connectors — anything with write access to the site.

Pro Tip: Keep a plain-text incident log from minute one: timestamps, who did what, and why. It feels like overhead during a crisis, but it’s the single document that makes root-cause analysis, client reporting, and any insurance or compliance claim afterwards dramatically faster.

Resist the urge to delete anything you think looks malicious at this stage. A file that looks like junk to you might be the exact evidence a forensic review needs to identify how attackers got in and whether they’re still inside. Containment is about stopping the bleeding, not cleaning the wound. That comes next, and it needs a clearer picture of what actually happened.

How do you know how bad a WordPress hack really is?

Not every compromise needs the same response. A single injected spam link in a footer widget is a different problem to a webshell sitting quietly in your uploads folder for three weeks. Getting the severity assessment wrong in either direction wastes time: over-reacting to a minor defacement burns budget you didn’t need to spend, while under-reacting to a persistent backdoor means you’ll be back here within a month.

Start by looking for the signs that confirm a hack rather than a bug:

Once you’ve confirmed something’s wrong, the investigation moves to logs. Web server logs will show unusual POST requests, repeated login attempts, or access to files that shouldn’t be publicly reachable. WordPress’s own activity logs (if you have a logging plugin installed) can reveal plugin installs, user creation, or file edits outside normal working hours. Firewall or WAF logs, where available, often show the exact request that triggered the compromise, and the database itself needs checking for injected wp_options entries, rogue administrator accounts, or spam content stored directly in post tables rather than rendered through templates.

From there, categorise what you’re dealing with. A single compromised plugin with a defacement or spam injection is usually containable within a day using the cleanup workflow below. A persistent remote code execution vulnerability, evidence of data exfiltration, or signs the attacker has been inside for an extended period is a different category entirely, and it’s where you preserve a full forensic copy of the compromised state and consider bringing in a dedicated cyber incident response (CIR) firm rather than handling it in-house. NCSC’s own advice on preserving evidence during recovery makes the same distinction: minor incidents get resolved quickly by competent technical staff, but anything touching customer data or showing signs of a sustained intrusion needs proper investigation before you do anything else.

How do you know how bad a WordPress hack really is? — overview diagram

How do you remove malware and backdoors from WordPress?

Cleaning an infected site properly means working somewhere the attacker can’t watch you do it. Set up a staging copy, or an isolated environment entirely separate from the live server, and keep an untouched forensic copy of the compromised state before you change a single file. If you clean the only copy of the infected site and later discover you missed something, you’ve lost your evidence and your fallback in one move.

The cleanup itself follows a repeatable sequence:

  1. Replace WordPress core files entirely with fresh downloads from wordpress.org rather than trying to identify which core files were modified. Core is small enough that wholesale replacement is faster and safer than line-by-line comparison.
  2. Compare plugins and themes against known-good versions. Anything you don’t recognise installing, or any premium plugin you can’t verify the source of, gets removed and reinstalled from a trusted copy rather than patched in place.
  3. Hunt for backdoors systematically. Look for PHP files in /uploads/ (a directory that should never execute PHP), unusually named files in theme or plugin directories, obfuscated or base64-encoded strings inside .php, .js or .xml files, and files with modification timestamps that don’t match a legitimate update. WordPress’s own hardening documentation flags exactly this kind of non-obvious persistence as the part most cleanups miss.
  4. Check scheduled tasks and cron jobs. Malicious WP-Cron entries or server-level cron jobs are a favourite way for attackers to re-inject code even after you’ve cleaned the visible files.
  5. Inspect .htaccess for injected rewrite rules that silently redirect specific visitors, particularly search engine crawlers, while leaving the site looking normal to everyone else.
  6. Search the database directly, not just through the WordPress dashboard. Check wp_options for injected values, wp_users and wp_usermeta for accounts you didn’t create, and post tables for spam content stored as draft or hidden posts.
  7. Document every change as you make it. This is the record you’ll need for the client conversation, for any compliance obligation, and for your own post-incident review.
  8. Rotate every secret the site depends on — security keys and salts in wp-config.php, database credentials, and any API keys or tokens used by third-party integrations. An attacker who had file access may have copied these even if you’ve removed their visible foothold.

Misconfigurations that go unnoticed for months are often what let an initial compromise turn into a persistent one. Open user registration left enabled by default, overly permissive file permissions, theme or plugin file editing left switched on in the dashboard, and unmonitored cron jobs are the specific weak points flagged in the NHS England Digital cyber alert covering the exploitation of CVE-2026-63030 and CVE-2026-60137 in WordPress Core, a vulnerability chain that allowed SQL injection and remote code execution across affected 6.8.x, 6.9.x and early 7.0.x installs. Sites running unpatched versions in that range needed updating to a fixed, supported version, alongside blocking anonymous REST API access as an interim mitigation while patches rolled out.

Once the file system and database are clean, run a second full scan before you consider the job done. For a fuller walkthrough of this sequence with worked examples, Wpcto’s step-by-step recovery guide covers the same workflow in more depth.

Hands unplugging USB from external drive

Should you restore a backup or clean the live site?

Restoring a backup feels like the fast option, and sometimes it is. But a backup restored without knowing how the attacker got in the first place just puts the same vulnerable code back online, ready to be exploited again within days. NCSC’s guidance on recovery is blunt about this: rushing to restore systems without investigation is one of the most common causes of repeat compromise, because the entry point never gets fixed.

That doesn’t mean restoring is always wrong. If you have a backup taken before the compromise began, and you’ve confirmed it, restoring can genuinely be the quickest safe path back to a working site. The key word is confirmed. Before you restore anything to production:

If none of your available backups clearly predate the compromise, or you can’t be confident they’re clean, cleaning and rebuilding the live site is the safer route, even though it takes longer. A backup that might be infected isn’t a shortcut. It’s just deferring the same problem to a later date.

Pro Tip: A backup you’ve never test-restored is a hope, not a plan. Schedule a quarterly test restore into staging for every client site on a maintenance plan; it’s the only way to know your recovery process actually works before you need it under pressure. Wpcto’s guide to choosing the right backup approach sets out what a properly validated backup regime looks like for agencies managing multiple client sites.

Once you’ve validated the restore in staging, promote it to production during a low-traffic window, and keep the archived copy of the infected state somewhere safe rather than deleting it. You may need it later for a compliance review, an insurance claim, or simply to double-check your own root-cause analysis once the pressure is off.

Agencies weighing up whether recovery work like this is worth absorbing internally or quietly costing more than it earns can run the numbers properly using the WordPress Profit Calculator rather than guessing at the true cost of an unplanned recovery.

What hardening steps stop the same hack happening again?

A cleaned site is not a secure site. It’s a site that’s temporarily free of the specific problem you found, which is a different thing entirely. The gap between those two states is where most repeat compromises happen, usually within weeks of the first clean-up.

Work through hardening as a checklist rather than a vague intention:

  1. Update WordPress core, every theme, and every plugin to their currently supported versions, and remove anything installed but unused. Dormant plugins are still attack surface even if nobody’s touched them in a year.
  2. Enforce least privilege across every user account. Nobody needs Administrator access to write blog posts; Editor or Author roles cover most day-to-day work without the ability to install plugins or edit files.
  3. Require strong, unique passwords and enable two-factor authentication for every account with admin or editor access, no exceptions for “just this once” client requests.
  4. Set DISALLOW_FILE_EDIT to true in wp-config.php so the theme and plugin editors in the dashboard can’t be used to inject code, and restrict wp-admin access by IP where the client’s workflow allows it.
  5. Block anonymous REST API access where the site doesn’t need it publicly exposed, a specific mitigation called out during the active exploitation of the WordPress Core vulnerability chain that affected sites running unpatched 6.8.x and 6.9.x releases.
  6. Deploy a web application firewall with rules tuned to WordPress-specific attack patterns, not just generic traffic filtering.
  7. Set up file-integrity monitoring so unexpected changes to core files trigger an alert rather than sitting unnoticed for months.
  8. Schedule recurring test restores, not just recurring backups, so you know the recovery process works before you’re relying on it during a real incident.
  9. Build an incident playbook and run it as a tabletop exercise at least once a year with your team, because a plan nobody’s practised falls apart the first time it’s needed for real.

These controls line up closely with the WordPress security hardening guidance published in the official developer handbook, and Wpcto’s agency guide to WordPress security walks through how to fold each of these into a standing maintenance schedule rather than treating them as a one-off post-incident task.

How do you clear a Google malware warning after a hack?

Getting the site technically clean is only half the job if search engines and browsers are still flagging it. Warnings tend to outlast the actual infection by days or weeks if you don’t actively request a review, which means visitors keep seeing red screens long after the problem’s gone.

Once you’re confident the clean-up is thorough:

How does NCSC guidance shape a staged WordPress recovery?

NCSC’s framework for recovering from a cyber incident isn’t WordPress-specific, but it maps almost exactly onto what a competent agency should be doing anyway. The core idea is staged recovery: contain the incident first, restore only the minimum viable operations needed to function, then rebuild properly rather than rushing a full restoration under pressure.

That staging matters because NCSC explicitly warns against restoring systems immediately without investigation, precisely because doing so tends to reintroduce whatever vulnerability caused the problem in the first place.

How do you tell clients and visitors about a WordPress hack?

Silence is the worst option once you know a site’s been compromised. Clients who find out about a breach from a Google warning or an angry customer email, rather than from you, lose trust fast, and that damage often outlasts the technical incident itself.

A workable communication plan has three audiences, each needing something slightly different. The client needs a factual, honest summary as soon as containment is underway, not a polished final report days later, covering what happened, what’s being done, and a realistic timeline. Vague reassurance without specifics tends to make people more anxious, not less.

Site visitors and end users need to know only what actually affects them. If personal data may have been exposed, they need clear, plain-language notice of what happened and what to do next. If the compromise was purely a defacement with no data exposure, a brief note isn’t always necessary, but you should have that judgement ready to defend if asked.

Internally, your own team needs a single point of contact managing outward communication so the client doesn’t get three slightly different versions of events from three different people. Agree the messaging before the first client call, not during it. Where the incident may involve personal data, this communication plan overlaps directly with legal notification obligations, which is where the next consideration comes in.

If the compromise involved access to personal data, communication obligations become legal ones, not just good practice. Data protection law in most jurisdictions, including the UK’s UK GDPR regime, sets a notification clock running from the point a breach is identified, and that clock doesn’t wait for you to finish the technical clean-up first.

The specifics vary by jurisdiction and by what data was exposed, so this isn’t something to guess at. What agencies should establish quickly, ideally as part of a client’s onboarding rather than mid-incident, is who’s actually the data controller for the site in question, because that determines who carries the legal notification burden. An agency managing a client’s WordPress site under a support retainer isn’t automatically the party responsible for regulatory reporting; that’s usually the client, unless your contract says otherwise.

Practical steps once a data-related compromise is confirmed: establish what data category was accessed (contact details, payment information, health data, and so on carry very different obligations), identify the responsible controller, and get legal advice on notification timing and wording rather than drafting it yourselves under time pressure. Document every decision made about notification, including the reasoning if you decide notification isn’t required, because that record matters if the decision is ever questioned later.

What does a hacked WordPress site actually teach agencies?

The conventional advice treats a hack as a one-off emergency to be survived and forgotten. That’s the wrong frame, and it’s why so many agencies get hit twice by the same class of vulnerability within a year.

The research is consistent on one point that most write-ups underplay: restoring without investigating is the single most common cause of repeat compromise, not a lack of technical skill during clean-up. Agencies are generally competent at removing malware. They’re far less consistent at asking why the malware got in, and that gap is where NCSC’s staged recovery model earns its place, forcing containment and investigation before restoration rather than after.

What I’d prioritise differently: treat every hack as a signal about your maintenance gaps, not just an isolated incident. If a client site got compromised, it’s worth asking honestly whether it was on a proper monitoring and patching plan at all, because most aren’t. That’s not a technical failing so much as a commercial one, and it’s usually the more valuable conversation to have with the client once the fire’s out.

— Marcel

Need help recovering or protecting a client’s WordPress site?

Recovering a hacked site under pressure, while still running your studio’s actual client work, is exactly the kind of task that eats a week and earns you nothing extra for it. Wpcto exists to take that off your hands entirely: emergency recovery, malware removal, and ongoing SLA-backed maintenance, delivered white-label so your client only ever sees your agency.

Wpcto

If you’re not currently charging for WordPress maintenance, or you’re absorbing hours like this one unbilled, it’s worth two minutes to see what that’s actually costing you. Wpcto’s WordPress Profit Calculator shows the uncaptured recurring revenue sitting in your existing client base in under 90 seconds, no sign-up required. For agencies wanting to hand off delivery entirely while keeping the client relationship and the margin, Wpcto’s agency services page covers recovery, monitoring, and maintenance under one SLA. Run the numbers, then get in touch about your next hacked-site call before it happens at 11pm on a Friday.

Sources

Secret Link