A WordPress security breach is not the time to install three security plugins and hope for the best. First, stop the attacker from making new changes. Then preserve enough evidence to determine what happened, restore from a known-clean point if possible, and close the entry path. A site that merely looks normal can still contain a backdoor, stolen administrator session, poisoned scheduled task, or modified plugin file.
For a WooCommerce store, containment also protects customer trust and active checkout revenue. For an agency, it prevents one compromised credential or deployment workflow from becoming a client-wide incident.
Contain the WordPress Security Breach First
If the site is actively redirecting visitors, sending spam, creating administrator accounts, or modifying files, put it behind a maintenance page or restrict public access at the server or CDN layer. Do not start deleting files while the attacker can still write to the server.
Take a full snapshot before remediation: web files, database, access logs, error logs, PHP logs, and any web application firewall events. This snapshot is evidence. It can reveal the initial entry point, affected accounts, and the first malicious change. It also gives you a rollback option if a cleanup step damages production.
Next, rotate credentials from a clean device. Start with hosting control panel, SSH/SFTP, WordPress administrators, database users, CDN accounts, domain registrar access, and email accounts used for password resets. Reset WordPress authentication cookies by changing the security salts in `wp-config.php`. This forces all users to sign in again.
If you manage the server, temporarily block suspicious source IPs and disable vulnerable endpoints only when necessary. Blocking `xmlrpc.php`, for example, may be reasonable on a site that does not use it, but it can break mobile apps, Jetpack functions, and some integrations. Apply restrictions based on actual use, not folklore.
Confirm What Changed
A clean-looking homepage proves nothing. Attackers commonly inject code into plugin files, active theme files, `wp-config.php`, `wp-content/uploads/`, must-use plugins, and the database. The uploads directory deserves special attention because PHP should rarely execute there on a standard WordPress site.
Start by checking recently modified files and unknown PHP files in writable directories. On a Linux server, this command identifies files changed in the previous seven days:
find /path/to/wordpress -type f -mtime -7 -printf '%TY-%Tm-%Td %TT %p\n' | sortReview results in context. A deployment, cache warmup, image optimization job, or scheduled backup may legitimately touch files. Look for obfuscated payloads instead: long encoded strings, `eval`, unexpected `base64_decode`, `gzinflate`, remote includes, or code that writes new files during requests.
Use WP-CLI to verify WordPress core files against official checksums:
wp core verify-checksums --path=/path/to/wordpress wp plugin status --path=/path/to/wordpress wp theme status --path=/path/to/wordpressChecksum verification catches modified core files, but it does not inspect premium plugins, custom themes, database injections, or server-level persistence. Treat it as one signal, not a clean bill of health.
In the database, inspect the `wp_users` and `wp_usermeta` tables for unfamiliar administrator accounts. Check active plugins and theme settings in `wp_options`, along with scheduled tasks. Attackers often use WP-Cron to restore malware after a superficial cleanup. Search posts, widgets, and options for injected scripts, hidden iframe tags, unfamiliar JavaScript domains, and encoded content.
Restore Cleanly Instead of Cleaning Blindly
The safest recovery is usually a restoration to a backup created before the compromise, followed by disciplined updates and credential rotation. That only works if you can identify a credible clean restore point. A backup from yesterday may already include a backdoor inserted weeks ago.
Build a timeline from file timestamps, user creation dates, access logs, malware scanner results, and customer reports. If logs show the first suspicious POST request on Tuesday, a Monday backup is a stronger candidate than one taken Tuesday evening.
For a custom site, avoid restoring the entire database without review. You may overwrite legitimate orders, form submissions, memberships, or content changes. A better approach is often to restore files and code from a clean point, then selectively review the current database for malicious records. WooCommerce stores need particular care here: orders and customer data are business records, not disposable cache.
If no trustworthy backup exists, replace rather than patch. Download a fresh copy of WordPress core, reinstall every plugin and theme from its original trusted source, and restore only reviewed custom code and uploads. Remove inactive plugins and themes you do not need. Attackers can hide in abandoned components just as easily as active ones.
Do not copy an entire `wp-content` directory into a fresh installation without inspection. That shortcut frequently carries the infection forward through uploads, cache directories, mu-plugins, or a compromised theme.
Find the Entry Point Before Reopening Access
A WordPress security breach repeats when the original weakness remains open. The usual causes are unpatched plugins, stolen credentials, exposed administrator accounts without multi-factor authentication, pirated extensions, insecure file permissions, or a vulnerable neighboring site on the same server account.
Review server access logs around the first confirmed malicious event. Look for requests to plugin files, unusual POST traffic to `wp-login.php`, successful logins from unfamiliar locations, or requests immediately followed by file writes. PHP error logs can also expose a vulnerable function or plugin path that was triggered repeatedly.
Check the operational basics:
- Update WordPress core, plugins, themes, PHP, and the operating system to supported versions.
- Remove nulled plugins and themes completely. Their source cannot be trusted, even if a scanner finds nothing.
- Require unique passwords and multi-factor authentication for every administrator, hosting account, and deployment service.
- Set file ownership and permissions so the web process cannot modify code unnecessarily.
- Separate staging from production credentials, databases, and API keys.
Be careful with security plugins that promise to fix everything automatically. They can help detect changed files and block common attacks, but they cannot repair a compromised hosting account, revoke stolen registrar access, or distinguish every legitimate custom modification from malicious code.
Harden the Site Without Breaking It
After restoration, reduce what an attacker can reach. Disable the built-in plugin and theme editor so a stolen WordPress admin account cannot edit PHP from the dashboard:
define('DISALLOW_FILE_EDIT', true);Keep this in `wp-config.php` above the line that says to stop editing. This setting does not stop file uploads or plugin installation by an administrator. If your operational model allows it, restrict plugin and theme installation to a controlled deployment process rather than routine dashboard access.
Protect `wp-config.php` and prevent PHP execution in upload directories at the web server level. The exact rule depends on NGINX, Apache, or LiteSpeed, so do not paste generic rules into production without testing. A rule that blocks PHP under uploads is normally safe, but custom applications sometimes store generated files in nonstandard paths.
Rate-limit login attempts at the edge or web server, enable multi-factor authentication, and review administrator accounts monthly. For agencies, use named individual accounts rather than one shared admin login. Shared credentials make incident investigation almost impossible and leave access behind when staff or contractors change.
Backups need their own security design. Keep multiple restore points, store copies off-server, and test a restoration on staging. Automated hourly backups are especially useful for high-volume WooCommerce sites, where restoring a day-old database can mean losing a day of orders. But backup frequency does not replace retention: you need enough historical points to recover from a compromise discovered late.
Make Hosting Part of the Recovery Plan
Security and performance operations overlap more than most site owners expect. Slow, overloaded servers produce incomplete logs, delayed malware scans, failed backups, and rushed changes during an incident. Clear resource boundaries, useful log access, isolated accounts, and fast restoration matter as much as a security checklist.
A managed platform should be able to tell you which PHP process wrote a file, when a backup completed, how quickly a restore can be staged, and whether the account shares risk with unrelated sites. At WP Tango, the same operational focus behind dedicated AMD Ryzen 9950X infrastructure also supports fast diagnosis, tested restore workflows, and predictable capacity when a site needs attention immediately.
Once the site is stable, document the incident: the entry point, affected files and data, restore point, credentials rotated, and preventive changes. That record turns a painful outage into a procedure your team can execute calmly the next time an alert appears.
