Hacked WordPress: 5 Essential Steps in the First 24 Hours

Your hacked WordPress site doesn't have to be a disaster. Follow this proven 5-step protocol — isolate, document, clean, and harden within 24 hours.

Hacked WordPress: How to React Before Making Things Worse

Discovering you have a hacked WordPress site triggers an instinctive reaction: wipe everything, reinstall, and move on. That impulse is understandable — but it’s exactly what can turn a manageable incident into an irreversible disaster. The first 24 hours after detecting a breach are the most critical, and what you do — or fail to do — during that window will determine whether you recover the site securely or whether the attacker walks back in within days.

This article covers the complete protocol: from the initial isolation of the site to the minimum hardening measures that should be in place before those first 24 hours are up. This isn’t a theoretical guide — it’s the actual process I follow when a client contacts me saying something is wrong with their site.

Real Signs That Your WordPress Has Been Hacked

Before you act, you need to confirm. Many site owners mistake a plugin error for a hack, and vice versa. These are the signs that point to a real intrusion — not a technical glitch:

• Redirects to external sites: the site redirects visitors to spam pages, pharmaceutical sites, or gambling platforms. This sometimes only happens when visitors arrive via Google, not when you type the URL directly.
• Unknown admin users: administrator accounts appear that no one on the team created.
• Recently modified core files: WordPress core files such as wp-config.php, index.php, or .htaccess show recent modification dates without anyone having touched them.
• Google Search Console alerts: notifications of “security issues detected,” or indexed pages with content you don’t recognize — Japanese, Cyrillic text, pharmaceutical links.
• Unexplained performance drops: the server is consuming disproportionate resources due to background processes — typically cryptomining scripts or mass spam sending.
• Bounced emails: your domain has ended up on spam blacklists because the server is sending thousands of unsolicited emails.

If you identify one or more of these signs, it’s time to switch into incident mode. Don’t keep browsing the WordPress dashboard as if nothing has happened.

Step 1: Isolate the Hacked Site Immediately

Your first move is not to clean. It’s to isolate. The goal is twofold: protect visitors from being affected, and prevent the attacker from continuing to operate while you investigate.

How to Isolate Correctly

• Enable maintenance mode at the server level: don’t use a WordPress maintenance plugin for this — WordPress itself may be compromised. Ask your hosting provider to block HTTP traffic to the site, or if you have server access, create a .maintenance file in the root directory, or add an .htaccess rule that returns a 503 to all requests except your own IP.
• Change passwords immediately: FTP/SFTP, hosting control panel, database, and all WordPress administrator accounts. Do this from a device other than the one you used to access the compromised dashboard.
• Revoke active sessions: if you can still access wp-admin, go to Users → your profile → “Log out of all other locations.” Repeat for every admin user.
• Disconnect external integrations: if the site connects to third-party APIs, payment gateways, or CRMs, temporarily revoke all access tokens. An attacker with server access can read API keys stored in wp-config.php or in the database.

This step should take between 15 and 30 minutes. Don’t move to the next one until the site is completely isolated from public traffic.

Step 2: Forensic Backup — Document Before Touching Anything

This is where most people make the critical mistake. The instinct is to “delete the malware now,” but if you remove files before documenting, you lose the ability to understand what happened, how they got in, and whether there are hidden backdoors that will survive your cleanup.

What Is a Forensic Backup and Why It Differs from a Regular One

A conventional backup saves your site so you can restore it. A forensic backup saves the compromised state so you can analyze it. The difference is crucial: you’re not going to restore from this backup — you’re going to study it.

How to Create the Forensic Backup

1. Full file copy via SFTP: download the entire site folder, including wp-content/, core files, .htaccess, and wp-config.php. Use SFTP (never plain FTP) and save everything in a local folder labeled with the date and time.
2. Export the full database: access phpMyAdmin or use mysqldump and export all tables. Not just the WordPress tables — if you share the database with other applications, export everything.
3. Capture server logs: the access.log and error.log files from Apache or Nginx contain the HTTP requests the attacker made. These logs are invaluable for later analysis. Many hosts rotate logs every 24–48 hours, so download them as soon as possible.
4. Screenshot Google Search Console: take screenshots of security alerts, suspicious indexed pages, and any manual actions applied.

All of this material should be saved to a local drive or cloud storage that is separate from the hosting environment. Never store it on the compromised server itself.

Step 3: Identify the Entry Vector

With the forensic backup in hand, it’s time to understand how the attacker got in. According to data from Wordfence, in more than 50% of hacked WordPress sites the entry point is a plugin or theme with known vulnerabilities. Other common vectors include:

• Weak or leaked credentials: reused passwords that appear in public breach databases.
• Outdated PHP or WordPress core versions: PHP versions without active security support (below 8.1 as of late 2026) or WordPress versions with known CVEs.
• Incorrect file permissions: files with 777 permissions, or uploads directories with PHP execution enabled.
• Compromised shared hosting: on cheap shared hosts, a hacked neighboring site can escalate to yours if account isolation is poor.

How to Trace the Entry Vector

Review the access logs looking for POST requests to unusual files inside wp-content/plugins/ or wp-content/uploads/. Attackers typically upload a PHP file (a webshell) to the uploads folder and then execute it remotely. Look for files with random names (xk4j2.php, cache-loader.php) in locations where executable PHP files should not exist.

Compare the core files from the forensic backup against the original WordPress files using diff or tools like WP-CLI (wp core verify-checksums). Any discrepancy indicates malicious modification.

Step 4: Clean Your Hacked WordPress Site

Only after isolating, documenting, and identifying the entry vector should you begin the actual cleanup. Order matters.

Reinstall the WordPress Core

Download a fresh copy of WordPress from wordpress.org and replace all core files — the wp-admin/ and wp-includes/ folders, plus the root files, except for wp-config.php and .htaccess. Don’t use the “Reinstall” button in the WordPress dashboard — do it manually via SFTP to ensure the original files are fully replaced.

Clean wp-config.php

Open the wp-config.php from your forensic backup and compare it line by line against a clean version. Look for injected code at the beginning or end of the file — typically eval() calls, base64_decode() functions, or remote file inclusions. Regenerate the security keys (salts) — this invalidates all active sessions, including those belonging to the attacker.

Review and Reinstall Plugins and Themes

Don’t just update them. Remove every plugin and theme, then reinstall them from scratch by downloading them from the official repository or the original vendor. This ensures any files injected inside plugin folders are eliminated entirely. Plugins you no longer use should be deleted — a deactivated plugin still present on the server remains an attack vector.

Clean the Database

Search the wp_options table for entries with suspicious values (external URLs, base64-encoded code). Review the wp_users table and remove any user account you don’t recognize. Check the wp_posts table for injected content — it’s common to find spam pages in Japanese or Turkish published as hidden posts.

Step 5: Essential Hardening Within 24 Hours

Cleaning without hardening is like closing the door without locking it. Before the first 24 hours are up, the following measures must be active:

Mandatory Hardening Measures

• Disable PHP execution in wp-content/uploads/: add an .htaccess file in that folder with the directive php_flag engine off (Apache) or the equivalent rule in Nginx. 90% of webshells are uploaded to this directory.
• Disable the built-in file editor: add define('DISALLOW_FILE_EDIT', true); to wp-config.php. This prevents an attacker with dashboard access from editing PHP files directly.
• Limit login attempts: implement rate-limiting for wp-login.php and xmlrpc.php. If you’re not using XML-RPC (most modern sites don’t need it), block it entirely.
• Force HTTPS sitewide: if you haven’t done this yet, do it now. Redirect all HTTP traffic to HTTPS via .htaccess or server configuration.
• Update PHP: make sure the server is running a PHP version with active security support.
• Correct file permissions: files at 644, directories at 755, wp-config.php at 440 or 400.

Verify with Google

If Google flagged your site as dangerous, go to Google Search Console → “Security Issues” and request a review after completing the cleanup. This process can take anywhere from 24 hours to several weeks. In the meantime, users will see the red “This site may harm your computer” warning.

Common Mistakes in the First 24 Hours

After handling multiple compromised site incidents, these are the patterns that repeat themselves:

1. Restoring a backup without verifying it’s clean: if the attacker has been inside for weeks (without you noticing), your recent backups are also compromised. You need to find a backup that predates the initial intrusion — not the moment you detected it.
2. Changing passwords from within WordPress: if the attacker has an active webshell, they can capture your new password in real time. Change database and hosting credentials from your provider’s control panel, not from WordPress.
3. Focusing only on what’s visible: visible malware (redirects, spam) is just the payload. The backdoor is typically a discreet file with an innocent-looking name hidden in a subfolder of a legitimate plugin.
4. Not checking other sites on the same server: on a shared host or with multiple WordPress installations under the same account, the infection may have spread laterally.
5. Assuming your host will handle it: most shared hosts will notify you of the infection but won’t clean it. They’ll suspend your account and give you a deadline to fix it yourself.

Realistic Timeline: What Should Be Done Each Hour

A time-based reference for organizing your incident response:

• Hour 0–1: Confirm the intrusion. Isolate the site. Change hosting, FTP, and database passwords.
• Hour 1–3: Complete forensic backup (files + database + logs). Revoke external API tokens.
• Hour 3–8: Analyze the entry vector. Identify modified files and backdoors.
• Hour 8–16: Cleanup: reinstall core, install clean plugins and themes, clean the database.
• Hour 16–24: Essential hardening. Functional verification of the site. Submit a review request in Google Search Console if applicable. Controlled reopening to traffic.

This timeline assumes an experienced person working the incident full-time. If the site is a WooCommerce store with customer data, add time to assess whether personal data was exfiltrated — which could trigger a mandatory breach notification obligation under the GDPR within 72 hours.

FAQ: Hacked WordPress

Can I clean a hacked WordPress site myself?

It depends on your technical level. If you’re comfortable with SFTP, can read server logs, and understand the WordPress file structure, you can tackle the cleanup following this protocol. If the site is an e-commerce with sensitive data, or you have no experience with the command line, it’s better to work with someone who has handled this type of incident before.

How long does Google take to remove the “dangerous site” warning?

Once you submit a review request in Search Console, Google typically takes between 24 hours and 2–3 weeks to verify that the site is clean. If the review fails (because residual malware was found), you can submit another request — but each failed attempt may extend the timeline.

Are my automatic backups useful for restoring?

Only if the backup predates the actual intrusion — not the date you detected it. In many cases, the attacker has been inside for weeks or months before activating the visible payload. You need to review the logs to determine when the initial access occurred, and then find a backup that precedes that date.

Should I notify my customers or users?

If the site stores personal data (contact forms, user accounts, WooCommerce orders) and there are indications that data may have been accessed, the GDPR requires you to notify the data protection authority within 72 hours and, in some cases, to notify the affected individuals directly.

If you manage a WordPress site and would prefer to have a professional monitoring its security on an ongoing basis, you can review my WordPress maintenance service to understand what it covers and how it works.

// About the author

fernandodomecq

Freelance WordPress developer specializing in WooCommerce, integrations and AI. I write about web projects, agencies and technical best practices.

View all articles →