You opened your site this morning and something is wrong. A redirect, a fake login form, a defaced homepage, an angry email from a customer — however you found out, your WordPress site has been compromised. The next 24 hours determine how bad this gets.

This is a tactical guide. No fluff, no "stay calm" lectures. Work through the steps in order. Skip nothing.

Step 1: Take the site offline (first 60 seconds)

Before you do anything else, prevent further damage. Every minute the site is online is another minute the attacker can:

Add new admin accounts you don't yet know about
Inject malicious JavaScript that infects your visitors
Steal customer data from forms and database tables
Send phishing emails from your domain
Get your domain blacklisted by Google Safe Browsing

Take it offline using the fastest method available to you, in this priority order:

Cloudflare or your CDN (if you use one) — set the site to "Under Attack Mode" or enable a maintenance page. Fastest to deploy, doesn't require server access.
Hosting provider's site lock — most managed hosts (Kinsta, WP Engine, SiteGround, etc.) have a "Take site offline" button in the control panel.
cPanel / hosting file manager — rename your .htaccess file to .htaccess.compromised and create a new .htaccess containing only:
```
Order Deny,Allow
Deny from all
Allow from YOUR_IP_HERE
```
This blocks everyone except you.
SSH/SFTP — if you have shell access, rename wp-config.php temporarily. WordPress can't run without it. Make sure to back it up first.

If you have no way to take the site offline yourself, contact your hosting provider's emergency support line. Most have one. Use it.

Step 2: Lock down access (first 5 minutes)

Assume every credential the attacker could have touched is compromised. Rotate them all, in this order:

WordPress admin passwords — every administrator account. Use a password manager-generated 24+ character password. If you can't log in, reset via your hosting control panel's database access.
FTP/SFTP credentials — these often grant raw filesystem access; attackers love them.
cPanel / hosting account password — the master credential.
Database password — change in wp-config.php AND in your hosting panel's database settings.
Any reused passwords elsewhere — if you use the same password for the hacked site as for your email or domain registrar, change those too.
API keys — Stripe, Mailchimp, any third-party services configured in WordPress plugins.

Enable two-factor authentication on every account that supports it. If your WordPress installation didn't have 2FA, this is non-negotiable now.

Step 3: Assess what was breached (first hour)

Before you can restore, you need to know what was touched. Look in the following places, in order:

3a. Identify unauthorised admin users

Via phpMyAdmin or your hosting database panel, run:

SELECT user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;

Any account you don't recognise is a hostile addition. Note them — don't delete yet (they're evidence).

3b. Look for backdoor PHP files

Common attacker-planted backdoors live at predictable paths. SSH or via your file manager, check for files modified in the breach window in:

/wp-content/uploads/ (most common — uploads should NEVER contain .php files)
/wp-content/plugins/ (look for unfamiliar plugin folders)
/wp-content/themes/ (especially in inactive themes)
Site root (look for files like radio.php, cmd.php, shell.php, or oddly-named PHP files)

Search for PHP files in uploads:

find wp-content/uploads -name "*.php" -type f

Anything that returns is suspicious — uploads should never contain executable PHP.

3c. Check for modified core files

Compare your wp-includes and wp-admin directories against a known-good WordPress download of the same version. Any modified files are likely backdoored.

3d. Audit installed plugins and themes

Plugins added or recently updated in the breach window need scrutiny. So do plugins flagged on the WP Vulnerability Database for known active exploits.

Lines of code on a developer screen, representing forensic investigation of a hacked site

Step 4: Restore from a clean backup (first 24 hours)

This is the most reliable path back to a clean site. Trying to surgically remove malware while leaving the rest in place is a job for forensics specialists — for most SMB owners, restore is faster, cleaner, and safer.

4a. Identify a known-clean backup

Go back further than you think. Many WordPress compromises sit dormant for days or weeks before activating. If your breach was discovered on Friday but the site was being weird since Tuesday, restore from before Tuesday.

If your hosting provider does daily backups (most do), pick the oldest one within your retention window if you're uncertain.

4b. Don't restore everything blindly

A full restore replaces your site state — including any legitimate content, orders, comments, and customer accounts created since the backup. If you have an e-commerce site with orders since the backup date, you'll need to manually reconcile those after the restore.

Good practice: restore the filesystem from backup, but keep the current database if you've already cleaned the malicious admin users from it. This preserves recent legitimate data while removing planted backdoor code.

4c. Update everything before bringing the site back online

Before lifting the maintenance/offline state:

WordPress core to latest version
Every plugin to latest version (or remove plugins you don't actively need)
Active theme to latest version
PHP to current supported version (your hosting panel usually has a one-click upgrade)

Server room infrastructure, representing the backups and clean environment to restore from

Step 5: Investigate the root cause (first week)

Restoring without understanding how the attacker got in means they'll be back within days. The most common WordPress entry points, in rough order of frequency:

Outdated plugin with a known CVE — by far the most common. Check WP Vulnerability Database for any plugin you had installed.
wp-login.php brute force — weak admin password, no 2FA, no brute-force protection. If your admin user was named "admin" or "administrator", this almost certainly happened.
xmlrpc.php abuse — XML-RPC is enabled by default and is a popular brute-force target. Disable it unless you specifically need it.
Stolen credentials from elsewhere — credential stuffing using passwords leaked from other services where you reused them.
Compromised hosting environment — rare but happens. Cross-account contamination on shared hosting.
SQL injection or vulnerable theme/plugin code — especially custom-built themes or plugins from unverified sources.

Check your access logs (your hosting panel will have these) for:

Hundreds of POST requests to /wp-login.php from a single IP — brute force
Repeated POSTs to /xmlrpc.php with system.multicall payloads — XML-RPC amplification
GET requests with suspicious query parameters (?id=1 UNION SELECT, ?file=../../, ?cmd=) — exploitation attempts

Step 6: Notify stakeholders (UK GDPR obligations)

This is the step many SMB owners don't realise applies to them. Under UK GDPR (the Data Protection Act 2018), if customer data was accessed during the breach, you may have a legal obligation to notify the ICO within 72 hours.

Specifically:

If the breach is "likely to result in a risk to the rights and freedoms of natural persons" — notify the ICO within 72 hours of discovery.
If the breach is "likely to result in a high risk" — also notify the affected individuals directly without undue delay.
Even if you decide notification isn't required, you must document the breach internally with reasoning. The ICO can audit this.

Personal data on a typical WordPress site that triggers this requirement includes:

Customer names + email addresses (basically every WooCommerce or registration-enabled site)
Billing addresses
Order history
Customer message contents (contact form submissions, comments)

The ICO's online breach notification form is at ico.org.uk/for-organisations/report-a-breach/. Be honest about uncertainty — saying "we believe customer email addresses may have been accessed but cannot confirm" is acceptable. Saying nothing when you should have is not.

If you operate beyond the UK, similar obligations apply under EU GDPR (notify your country's supervisory authority) and various US state laws (notify state attorneys general — California, New York, and several others have strict requirements).

Step 7: Prevent recurrence

You've cleaned the site, identified the entry point, and notified anyone you needed to. Don't put it back online with the same defenses that failed last time.

The non-negotiable hardening list:

Real-time threat detection at the application layer. A WAF that inspects every incoming request and blocks SQL injection, XSS, brute force, scanner traffic before it reaches WordPress. This is what failed if your breach was an outdated plugin or a brute-force success.
Two-factor authentication on every admin account. Brute-force resistance becomes mathematical impossibility, not just "harder".
Disable XML-RPC unless you actively use it. Most sites don't need it. It's a pure attack surface.
Plugin minimalism. Every plugin is a potential entry point. Run with the smallest set you can.
Automated daily backups stored off-server. Your hosting backup is fine, but if your hosting account is compromised, those backups are too. Have an independent copy somewhere else (S3, Backblaze, even a separate Dropbox account).
Monitoring with alerts. The next breach should produce an alert in seconds, not when an angry customer emails you a week later.

If you don't already run a real-time security monitoring layer, our Obsyde Aegis plugin handles all of the above. It's free in the WordPress.org directory, runs locally on activation, and catches the attacks that get past plugin updates and password rotations.

What NOT to do

The most common mistakes that turn a manageable incident into a disaster:

Don't just delete the suspicious files and call it done. If you don't know how the attacker got in, they will get back in.
Don't try to "negotiate" with attackers if you receive a ransom message. Pay nothing — they have no obligation to deliver, and paying signals you're a viable target for re-attack.
Don't restore from a backup without changing all credentials first. The attacker often plants their stolen-credential backdoor before being detected. Restoring without rotating means they're still in.
Don't bring the site back online before patching the entry point. Same vulnerability + same site = same compromise within hours.
Don't ignore your customers. If their data may have been touched, tell them. Trying to quietly hide a breach almost always ends worse than disclosing it — both legally and reputationally.
Don't assume "it's just a small site, no one cares". Most WordPress compromises today are automated mass-scanning campaigns. Attackers don't care about your size, only your vulnerable surface.

When to call professionals

You can handle most WordPress incidents yourself. The threshold for engaging an incident response firm or specialist consultant:

Customer payment data was potentially accessed (PCI-DSS implications)
Health data, financial data, or other regulated categories were involved
The breach has been ongoing for weeks or months and you can't determine the scope
You suspect ongoing access despite cleaning attempts
You operate in a regulated industry (financial services, healthcare, government)
The incident may have B2B contractual implications (your customers' customers' data)

For UK SMBs, the National Cyber Security Centre offers free general guidance, and the Action Fraud service handles cybercrime reporting. Neither will do the cleanup for you, but both can advise on legal and procedural next steps.

Conclusion

WordPress compromises are common. They're also recoverable — most don't end the business that experiences one. What separates the businesses that recover from the ones that don't is execution speed in the first 24 hours.

To recap, in priority order:

Take the site offline (60 seconds)
Rotate every credential (5 minutes)
Identify what was breached (1 hour)
Restore from a clean pre-breach backup (24 hours)
Investigate the root cause (within a week)
Meet your legal disclosure obligations (within 72 hours)
Harden so it doesn't happen again

The hardening step is the one most owners skip after a successful recovery — and it's the one that determines whether you're back here in three months.

If you're reading this before a breach: install proper monitoring now. The marginal cost of prevention is always less than the cost of recovery — and the difference compounds with every customer record on the line.

Your WordPress Site Got Hacked: What To Do in the First 24 Hours