WordPress Hacked? A Calm Recovery Playbook

Discovering your WordPress site has been hacked triggers a very human response: panic, followed by the urge to start deleting things immediately. Resist both. WordPress hacked recovery is a methodical process, and the sites that recover fastest are the ones whose owners slow down, follow a sequence, and avoid making the damage worse in the first hour.

This playbook gives you that sequence: confirm, contain, investigate, clean, restore, and harden. Follow it in order and you will come out the other side with a clean site and a clear understanding of how the attacker got in.

Step 1: Confirm and Contain (First Hour)

Before anything else, confirm you are actually dealing with a compromise and stop the bleeding:

• Confirm the symptoms: defaced pages, unfamiliar admin users, spammy redirects, Google warnings, or visitors reporting antivirus alerts all indicate compromise. One strange plugin notice does not — verify before declaring an emergency.
• Take the site offline or restrict access if visitors are being harmed — malware serving, phishing pages, or spam redirects justify a maintenance page immediately. A brief outage beats infecting your audience.
• Do not delete anything yet. Attackers’ files are evidence. You need them to understand the entry point, and premature deletion destroys that information while usually missing the actual backdoors anyway.
• Change critical credentials from a clean device: hosting panel, FTP, and database passwords. Assume the attacker may have harvested anything stored on the server.

Step 2: Investigate Before You Touch Anything

With the site contained, investigate. Your goals are to find every malicious file and identify the entry point. Common hiding places:

• Recently modified files: sort your WordPress files by modification date. Core, theme, and plugin files you did not touch that changed recently are prime suspects.
• Unfamiliar files in uploads: the uploads directory should contain media, not PHP files. Any script here is malicious until proven otherwise.
• Unknown admin users: check the users list for accounts you did not create, especially administrators. Note their creation dates — they bound the intrusion timeline.
• Obfuscated code: search theme and plugin files for telltale patterns — eval combined with base64_decode, long encoded strings, or code appended to legitimate files.
• Scheduled tasks and mu-plugins: attackers persist through WordPress cron jobs and must-use plugins, which many owners never inspect.

Document everything you find: file paths, timestamps, user accounts. This record guides the cleanup and, if the entry point was a vulnerable plugin, tells you exactly what to update or remove.

Pro tip: compare your core files against a fresh WordPress download of the same version. Any core file that differs and you did not modify is compromised — no judgment call required.

Step 3: Find the Entry Point

Cleaning without closing the entry point guarantees reinfection. Work backward from your evidence:

• Check access logs around the timestamps of the first malicious file modifications. Look for requests to unusual endpoints, repeated probes of a specific plugin, or successful logins from unfamiliar IPs.
• Review recently updated or outdated components. The most common entry points are vulnerable plugins and themes — especially ones abandoned or long out of date.
• Consider credential compromise. If logs show a legitimate login from an unfamiliar location followed by malicious activity, the entry point was a stolen password, not a software flaw.
• Check for nulled or pirated themes and plugins. These frequently ship with backdoors pre-installed. If you find any, the entry point was the day they were installed.

If you cannot determine the entry point with confidence, assume the worst: treat every credential as compromised and every third-party component as suspect until verified.

Step 4: Clean Thoroughly

Cleaning means removing every trace of the compromise, not just the obvious defacement:

1. Remove all malicious files identified in your investigation.
2. Replace WordPress core with a fresh download of your version — do not try to disinfect core files individually.
3. Reinstall every theme and plugin from clean sources. For premium components, download fresh copies from the vendor; for free ones, reinstall from the official directory.
4. Remove unknown admin users and force password resets for all legitimate users.
5. Clear scheduled tasks you did not create and inspect must-use plugins.
6. Scan the database for malicious content: spam links injected into posts, malicious JavaScript in widget text or options, and rogue admin accounts created directly in the users table.

The database step is the one most people skip and most attackers count on. Malware in the database survives file replacement completely, so search every table methodically — posts, postmeta, options, and usermeta — before considering the cleanup done.

Step 5: Restore or Rebuild — Choosing Wisely

You have two paths to a clean site, and the right choice depends on your backups:

Restore from a known-clean backup

If you have a backup from before the intrusion — verified by the timestamps in your investigation — restoring it is the fastest reliable path. But “restore and done” is not enough: you must still close the entry point (update or remove the vulnerable component, reset credentials), or the restored site will be recompromised through the same hole.

Clean in place

If no clean backup exists, the manual cleaning process above, done thoroughly, produces a clean site. It is slower and demands more care — particularly the database review — but it works. Be honest with yourself about thoroughness: a rushed cleanup that misses one backdoor is worse than useless, because it creates false confidence.

Never restore a backup from after the intrusion began. That simply reinstalls the attacker’s work, backdoors included. When in doubt about a backup’s date relative to the intrusion timeline, treat it as compromised and clean manually instead — a wrong guess here undoes everything.

Communicating During the Incident

Recovery is technical, but a hack is also a communications event — especially if you run a store, a membership site, or anything holding user data. Plan your communication with the same calm as your cleanup:

• Be honest but precise. “We detected unauthorized access and took the site offline as a precaution while we investigate” is honest without speculating. Never claim “no data was affected” until you have actually verified it.
• Notify affected users promptly if personal data may have been exposed. Many jurisdictions require breach notification within strict timeframes — know your obligations before you need them.
• Force password resets for all user accounts if there is any chance credentials were exposed, and say so plainly when you do.
• Do not hide the incident from stakeholders or customers. Cover-ups that surface later destroy more trust than the incident itself ever could.
• Publish a brief post-incident summary once recovery is complete: what happened, what you did, and what changed to prevent recurrence. It turns an embarrassment into evidence of competence.

Keep a simple incident log as you work — timestamps of what you found and what you did. It keeps communication accurate and becomes invaluable if the incident has legal or compliance dimensions.

Step 6: Harden and Verify

A recovered site that is not hardened is a site waiting to be hacked again:

• Update everything: WordPress core, all themes, all plugins — on the theory that the entry point was a known vulnerability.
• Reset all secrets: database passwords, hosting credentials, API keys, and WordPress salts (changing salts forces every session and cookie invalid — logging out the attacker everywhere).
• Remove the vulnerable component if the entry point was a plugin or theme you can live without. The most secure vulnerable plugin is a deleted one.
• Enable two-factor authentication for all administrator accounts.
• Review file permissions and confirm nothing is left at 777 from the incident.
• Request a review in Google Search Console if your site carries a security warning — after verifying the site is genuinely clean.

Then monitor patiently and consistently. Watch for the symptoms’ return over the following weeks: unexpected files, new admin users, traffic anomalies. A reinfection within days means you missed the entry point or a backdoor — go back to Step 2 with fresh eyes.

Being hacked is miserable, but it is also survivable and educational. Almost every compromised site recovers fully following this sequence. The ones that do not are the ones that skipped steps — usually the investigation, usually the database, usually the entry point. Be thorough, be calm, and close the door behind you. And once the dust settles, write down what you learned: the entry point, the timeline, the fixes. That document becomes your site’s security baseline, and maintaining it is what turns a painful incident into lasting protection.