The first hour: don’t start deleting things
You open your WordPress dashboard and something’s wrong. Maybe visitors are being sent elsewhere, or your host has warned you about suspicious files. The first hour matters, but speed doesn’t mean deleting everything that looks odd. To fix a hacked WordPress site, you need to stop the damage, keep a copy of the evidence, then remove every way the attacker can get back in.
If you aren’t sure it’s a hack, check the signs your WordPress site has been hacked first. Otherwise, start here. This is what to do when your WordPress site is hacked, in a workable order.
Step 1: Contain the site
Don’t leave a compromised checkout taking orders while you investigate. A banner saying “we’re looking into it” won’t stop a malicious script from reading payment details or sending visitors to another site.
- If visitors are being redirected or checkout may be compromised, ask your host to take the site offline or put a maintenance page in front of it at the server level.
- For a WooCommerce shop, pause payments if the checkout may be affected. Contact your payment provider if you suspect payment details were exposed.
- Tell your host the site may be compromised. Ask them to preserve relevant access and error logs before they rotate or delete them.
A normal WordPress maintenance plugin may still run alongside malicious code. Use your host’s controls for serious cases. Keep a trusted way into the hosting account so you can investigate.
Step 2: Back up the hacked state
Before changing passwords, updating plugins or removing files, take a full copy of the site as it is now: files and database. Yes, you’re backing up the infection. That copy can show when a backdoor appeared, what changed in an order or post, and which account an attacker created. Without it, finding the entry point gets harder.
Use your host’s backup tool or make separate database and file exports, then store them away from the affected server. Label the copy clearly as compromised; don’t restore it casually. Ask the host for logs covering the suspected period too. If you can’t export safely yourself, ask them to do it before they clean anything.
Step 3: Take back access
Assume passwords and keys stored on the server might be known to the attacker. Change them from a device you trust, and don’t email new credentials around the team.
- Reset every WordPress administrator password. Check who still needs admin access.
- Change the hosting or cPanel password and every SFTP and SSH credential. Remove accounts you can’t identify.
- Rotate the database user’s password at the host, then update the matching value in
wp-config.phppromptly so the site can connect again. - Replace the WordPress security salts in
wp-config.php, rotate connected API keys, and revoke WordPress application passwords you no longer need.
New salts invalidate existing WordPress login cookies, logging users out. Also end active sessions through your security or hosting controls where available. If an attacker still has a backdoor, they can create another admin after all this. Password changes buy you room; they aren’t the cleanup.
Step 4: Find every backdoor
Start with a file and database inventory. Do it on a copy or in a controlled hosting environment, especially if the live site handles orders. The WordPress Users screen is useful, but it can lie: malicious code can hide an account from that page. Check the database’s wp_users and wp_usermeta tables directly. Your table prefix may differ from wp_; look for administrator capabilities, unfamiliar email addresses and accounts created around the incident.
- Inspect
wp-content/mu-plugins/, regular plugins and themes for anything you didn’t install. Must-use plugins don’t appear in the usual plugin list. - Look for PHP inside
wp-content/uploads/. Media uploads shouldn’t need executable PHP. - Review recent PHP changes with
find wp-content -type f -name '*.php' -mtime -7. Change the number of days to fit your timeline; an older backdoor won’t show up in this search. - Compare
wp-config.phpand.htaccesswith known-good copies. Check WP-Cron events and your hosting account’s server cron jobs. - Search database options in
wp_optionsand post content for injected scripts, redirects and strange administrator-related settings. Check the equivalent tables if your prefix differs.
Run wp core verify-checksums and wp plugin verify-checksums --all with WP-CLI. These help identify changed WordPress core files and plugins available through wordpress.org. They won’t prove the whole site is clean; custom and premium plugins need separate checks.
Why be this thorough? In an October 2026 campaign reported by Patchstack, injected scripts in Ninja Forms submissions and WPC Product Bundles WooCommerce orders ran when an admin opened them. The attack installed a fake “WP Smart Thumbnails” plugin, a visible admin, a hidden admin, a secret login link and a file manager. Some components sat in wp-content/mu-plugins/. Updating the affected plugin could stop new attacks, but it wouldn’t remove backdoors already there.
Step 5: Clean or rebuild from trusted copies
Editing a suspicious line out of a PHP file is tempting. I’d rather replace the whole file: you can’t tell what else was tucked into it. Replace WordPress core files with fresh copies, and reinstall wordpress.org plugins from fresh downloads. Get paid plugins and themes from their actual vendors. Keep wp-config.php and wp-content/ only after you’ve inspected them; don’t overwrite your uploads or configuration blindly.
Remove malicious users, files, scheduled tasks and database injections you’ve identified. If you have a backup from before the entry point, restoring it may be quicker. But a backup taken after the compromise can contain the same backdoor. If you don’t know when the hack began, a restore alone isn’t a fix.
Step 6: Close the way in
Work out how access was gained. Was a plugin left unpatched, an administrator password stolen, or an old SFTP account still active? If you skip this question, the attacker can return through the same door.
Update WordPress, plugins and themes after taking that evidence copy. Remove abandoned extensions, unused themes and any nulled software. Review administrator access and turn on two-factor authentication where possible. For a shop, test the cart, checkout, payment callbacks and order emails after changes. A site that loads its homepage but can’t complete an order isn’t repaired.
Once the immediate cleanup is done, set a routine for updates and backups. If you don’t have time to keep up with it, WordPress maintenance is a sensible job to hand off.
Step 7: Check the outside view and watch for a return
Open Google Search Console’s Security Issues report. If Google flagged the site, follow its guidance and request a review after you’ve removed the problem. Check whether your domain appears on major browser or security blocklists, then revisit those checks over the next few weeks.
Watch newly created users, changed files, outgoing redirects, unfamiliar cron tasks and fresh warnings from your host. Keep backups during this period. If the same strange file comes back, don’t just delete it again; something is recreating it. Our guide to why a site gets reinfected after cleanup explains where to look next.
When to call a professional
Get help if you find a hidden admin, a repeat infection, or signs that a shop’s customer data may be affected. The same goes if you can’t establish a clean backup or don’t have safe access to the database and hosting logs. It’s easy to remove the visible mess and leave the file manager behind.
For EU businesses, a possible personal data breach needs prompt assessment. Under GDPR Article 33, you may have to notify your data protection authority within 72 hours of becoming aware of a breach. Document what you know and get appropriate legal or privacy advice; don’t wait for a perfect technical answer before assessing that duty. If you want us to handle the investigation and repair, see our WordPress hack cleanup service.
Do this first
If the site is still live and you suspect its checkout or redirects have been tampered with, contact your host now and ask them to put a server-level maintenance page in front of it while preserving logs. Then take the files-and-database backup. Don’t delete the clue that tells you how the attacker got in.