My WordPress Site Was Hacked: What to Do Right Now

Your site is redirecting to a spam page. There is content you did not write showing up in Google. Your hosting provider sent a suspension notice. You found admin accounts you did not create. Something is wrong and you need to fix it now.

This guide is the step-by-step response. Follow it in order. Each step matters and the sequence matters.

Step 1: Do not panic, but act quickly#

A hacked site feels urgent, and it is – but rushing without a plan causes more damage than the hack itself. Deleting files randomly, restoring backups blindly, or reinstalling WordPress without understanding how the attacker got in will leave you in a worse position. The attacker comes back through the same hole, or you overwrite evidence you needed.

Take 10 minutes to read through this entire guide before you start executing. The malware is already on your site – those 10 minutes will not make it worse, but acting without a plan might.

Step 2: Document what you see#

Before you change anything, write down what is happening. You will need this information later when identifying the entry point and when talking to your hosting provider or a security professional.

Document:

• What symptoms you noticed. Redirects? Spam pages? Google warning? Hosting suspension? Slow performance?
• When you first noticed it. The exact date and time narrows down when the compromise happened.
• What changed recently. Did you install or update a plugin? Change a theme? Add a new user? Give someone access?
• Screenshots. Take screenshots of the symptoms – the redirect destination, the spam search results, the Google warning, any suspicious content. These may disappear once you start cleaning up.

Open your browser’s developer tools (F12) and check the page source for injected scripts or iframes you cannot see on the rendered page. Some malware is invisible to visitors but present in the HTML.

Step 3: Change all credentials immediately#

Assume the attacker has every password that was stored on or accessible from your server. Change them all, starting with the most critical:

WordPress admin passwords. Log in and change the password for every administrator account. If you cannot log in because the attacker changed your password or created a redirect that prevents access to wp-login.php, skip this and come back to it after you regain file access in the next steps.

Database password. Change the MySQL/MariaDB password through your hosting control panel or via command line. After changing it, update the DB_PASSWORD value in wp-config.php to match. Your site will go down until both match – that is fine, it is coming down anyway.

Hosting account password. Change your control panel password and any FTP/SFTP passwords associated with the account.

SSH keys. If you use SSH key authentication, check ~/.ssh/authorized_keys for keys you do not recognize. Remove any unfamiliar keys. If in doubt, remove all keys and re-add only your own.

Email account passwords. If your email is connected to your WordPress admin account or your hosting account, change that password too. Attackers who have your email can reset everything else.

Do not reuse any previous password. Use a password manager to generate unique passwords for each service.

Step 4: Put the site in maintenance mode#

Take the site offline to stop the active damage. A hacked site that stays online continues to redirect visitors, serve malware, send spam, damage your search rankings, and potentially expose customer data.

Option 1: Maintenance mode via .htaccess (Apache/LiteSpeed)

Create or edit .htaccess in your WordPress root:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.ADDRESS$
RewriteRule ^(.*)$ - [R=503,L]
ErrorDocument 503 "Site temporarily unavailable for maintenance."

Replace YOUR.IP.ADDRESS with your own IP so you can still access the site while it is down for everyone else.

Option 2: Maintenance mode via hosting control panel

Most hosting control panels have a way to suspend or disable a site. This is the fastest option and does not depend on WordPress functioning.

Option 3: Rename wp-config.php temporarily

mv wp-config.php wp-config.php.disabled

This breaks WordPress completely. The site shows a setup screen instead of your content. It is blunt but effective – nothing runs, including the malware.

Step 5: Assess the damage#

Now that the bleeding is stopped, figure out what happened and how far it went.

Check file modification dates

Connect via SSH and look for recently modified files:

find /path/to/wordpress -name "*.php" -mtime -14 -type f | sort

This shows every PHP file modified in the last 14 days. Compare this list against changes you made intentionally (plugin updates, theme changes). Files modified that you did not touch are suspicious.

Pay special attention to:

• Core files.  wp-config.php , files in  wp-includes/ , files in  wp-admin/ . WordPress does not modify these between updates.
• The uploads directory. PHP files in  wp-content/uploads/  are almost certainly malware. WordPress does not store PHP files there.
• Plugin and theme files. Check modification dates against when you last updated each plugin.

Check access logs

Your web server access logs show every HTTP request to your site. Look for the attack:

grep "POST" /var/log/nginx/access.log | grep -v "wp-admin" | grep -v "wp-login" | tail -100

POST requests to unusual URLs – especially to plugin files, theme files, or uploaded files – are the most common exploitation pattern. Look for POST requests to files in wp-content/uploads/ or to plugin endpoints that should not accept POST data.

grep "wp-content/uploads/.*\.php" /var/log/nginx/access.log

Any requests to PHP files in the uploads directory are almost certainly exploit activity. The IP addresses making these requests are the attacker.

Check for backdoor accounts

wp user list --role=administrator

Or via the database:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
INNER JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Any admin account you do not recognize was created by the attacker. Note the user_registered date – it tells you roughly when the attacker had access.

Check for database injection

SELECT option_name FROM wp_options
WHERE option_value LIKE '%eval(%'
OR option_value LIKE '%base64_decode%'
OR option_value LIKE '%<script%'
OR option_value LIKE '%<iframe%';

SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<script%'
AND post_status = 'publish';

Injected scripts in the database are common. They survive file-level cleanup if you do not check.

Step 6: Identify the entry point#

Understanding how the attacker got in is critical. If you skip this step and just clean up, you will be hacked again through the same vulnerability – often within hours.

The most common entry points:

Vulnerable plugin or theme. Check your plugin versions against known vulnerabilities. Sites like WPScan Vulnerability Database and Wordfence’s blog publish disclosures. If any of your plugins had a disclosed vulnerability during the timeframe of the hack, that is very likely the entry point. See why WordPress plugin vulnerabilities are out of control for the scale of this problem.

Compromised credentials. Check your access logs for successful logins from unfamiliar IPs, especially around the time the compromise started. Brute force attacks against wp-login.php and xmlrpc.php leave clear patterns in logs – many failed attempts followed by a success.

File upload exploit. Look for the first PHP file that appeared in wp-content/uploads/ . Its creation date and the access log entry for the upload request tell you when and how the initial exploit happened.

Nulled plugin or theme. If anyone on your team installed a “free” version of a premium plugin or theme from an unofficial source, that is almost certainly the entry point. Nulled software contains embedded backdoors.

Step 7: Clean up or restore#

You have two options. Which one to choose depends on your situation.

Restore from backup

This is the faster and more reliable option when:

• You have a backup from before the compromise
• You know when the compromise started
• The backup is complete (files and database)

Restore the backup, then immediately:

1. Update WordPress core, all plugins, and all themes
2. Change all credentials (you already did this in step 3, but verify)
3. Delete the plugin or theme that was the entry point, or verify it is now patched
4. Verify the site is clean

The risk with restoring from backup is choosing a backup that is already compromised. If the malware was present but dormant for weeks before you noticed symptoms, your recent backups may all contain the malware.

Manual cleanup

Follow the detailed cleanup process in WordPress malware: how it gets in and how to remove it. The summary:

1. Replace WordPress core files with fresh downloads
2. Reinstall all plugins from clean sources (wordpress.org or vendor)
3. Review and clean theme files
4. Remove PHP files from the uploads directory
5. Clean wp-config.php of injected code
6. Remove backdoor admin accounts
7. Clean the database of injected scripts
8. Regenerate WordPress salts and authentication keys

Manual cleanup takes longer but gives you certainty about what was changed and ensures no malware survives in your backups.

Step 8: Verify the cleanup#

After cleaning up, verify the malware is actually gone:

Run a malware scan. Install Wordfence and run a full scan. It compares your files against known-good versions and checks for malware signatures.

Check from the outside. Use Sucuri SiteCheck (sitecheck.sucuri.net) to scan your site from an external perspective. Check Google Search Console for any remaining security warnings.

Monitor file changes. Over the next few days, watch for new file modifications. If the attacker still has a backdoor you missed, you will see new files appearing or existing files being modified.

find /path/to/wordpress -name "*.php" -newer /path/to/wordpress/wp-config.php -type f

This shows PHP files newer than wp-config.php. After a clean restore, there should be none unless you installed or updated something.

Test site functionality. Browse the site as a visitor. Check it on mobile. Search for your domain in Google and click through results. Some malware only activates for search engine traffic or mobile visitors.

Step 9: Handle customer data exposure#

If your site handles customer data – especially if you run a WooCommerce store – you need to determine whether customer data was accessed.

What to check

• Was the database accessed? If the attacker had access to wp-config.php, they had the database credentials. Assume the database was accessible.
• Was customer data in the database? WooCommerce stores order history, addresses, and account details in the database. Payment card numbers are not stored by WooCommerce if you use a standard payment gateway (Stripe, PayPal) – the gateway handles card data directly.
• Was there a payment skimmer? Check checkout page source code for injected JavaScript that captures form data. If a skimmer was present, card data may have been captured even if WooCommerce does not store it.

If customer data was exposed

• Notify affected customers. Be direct about what happened, what data was potentially exposed, and what they should do (change passwords, monitor payment statements).
• Check legal requirements. Many jurisdictions (GDPR in the EU, various state laws in the US) require breach notification within specific timeframes. Check what applies to your business.
• Force password resets. Reset passwords for all WordPress user accounts, not just administrators. Notify customers that they need to set a new password.

Step 10: Harden to prevent reinfection#

A clean site without hardening will be compromised again. Attackers share vulnerability data and target lists. If your site was vulnerable once, it is on lists that other attackers will scan.

Update everything and keep it updated

Update WordPress core, every plugin, and every theme. Set up a process to apply updates promptly going forward. Enable automatic updates for minor WordPress releases at minimum.

Remove what you do not use

Delete every plugin and theme that is not actively in use. Deactivated plugins are still exploitable – their PHP files are accessible via direct URL requests. Every plugin you remove is attack surface eliminated.

Enforce strong authentication

• Require strong, unique passwords for all admin accounts
• Enable two-factor authentication
• Limit the number of administrator accounts to the minimum necessary
• Use Editor or Author roles for content creators

Monitor continuously

Install a security plugin that monitors file integrity and alerts you to changes. Early detection is the difference between a quick cleanup and a major incident. Catching a backdoor file 10 minutes after it is created is a minor issue. Discovering it 3 months later is a crisis.

Use a web application firewall

A WAF blocks the most common attack patterns – SQL injection, cross-site scripting, file upload exploits, path traversal – at the web server level before they reach WordPress. It does not catch everything, but it blocks the automated tools that account for the vast majority of attacks.

How hosting infrastructure affects hack recovery and prevention#

The hosting environment your site runs on determines how bad a hack can get and how much protection you have before it happens.

Container isolation limits blast radius

On traditional shared hosting without proper isolation, a hacked site is not just your problem. The attacker can potentially pivot from your compromised WordPress installation to other accounts on the same server. Container isolation prevents this by running each account in its own isolated environment with separate process namespaces, filesystem mounts, and network access. A compromise affects one site, not the entire server.

Server-level bot detection blocks attacks before they start

Most WordPress hacks begin with automated scanning – bots probing your site for vulnerable plugins, exposed configuration files, and weak login credentials. A server-level bot detection system identifies and blocks these scanners based on behavioral signals before they find anything to exploit. This is fundamentally different from WordPress security plugins, which can only act after the request has already reached PHP.

Real-time malware detection catches compromises early

Server-level malware scanning that monitors file system changes in real time detects malicious files as they are created – not on a scheduled scan hours or days later. The difference between detecting a backdoor in seconds versus discovering it weeks later is often the difference between a minor incident and a full compromise.

Recovery on Hostney#

On Hostney, these infrastructure protections are built in:

• Bot detection blocks automated vulnerability scanners before they reach your site
• ModSecurity with the OWASP Core Rule Set blocks SQL injection, XSS, and other attack patterns at the web server level
• Container isolation ensures a compromise cannot spread to other accounts
• Real-time malware protection detects malicious files as they are created, quarantines them automatically, and reports the incident to the control panel
• Automated backups provide clean restore points

If your site on Hostney has been compromised, contact support. The team can review ModSecurity and access logs to identify when and how the compromise occurred, restore from a clean backup, and help with any post-recovery hardening.