How to Clean a Backdoored WordPress Site After a Bad Plugin
How to clean a backdoored WordPress site: restore a pre-compromise backup, remove the plugin, hunt persistence, rotate credentials, then reinstall.
To clean a backdoored WordPress site, restore files and the database from a backup taken before the compromise, then rotate every credential the site could read, and only then reinstall the affected plugin from a trusted source. If no clean backup exists, remove the infected component, hunt for the persistence it planted, and rebuild core, plugins and themes from known-good copies. This guide uses the Rank Math SEO PRO 3.0.123 malware incident as the worked example.
How do you know the site is backdoored?
Assume it is if the site ran a component the vendor has confirmed was malicious, or if you find indicators the vendor published. A clean scan does not prove otherwise, because many backdoors are written to avoid scanners.
For the Rank Math case, the vendor's indicators include outbound connections to rank1cdn[.]com, administrators with usernames starting wpsupport_, a fake core file at wp-includes/class-wp-cache-util.php, three odd rows in wp_options and system scheduled tasks tagged #ms6v46. Write down what you find before you change anything. You will need the list later to confirm the cleanup worked.
Step 1: Decide whether you can restore
Restoring from a pre-compromise backup is the fastest and most reliable route. It replaces every file and database row the attacker touched, including the ones you would not think to look for.
The backup has to predate the compromise, not the discovery. For Rank Math that means a backup taken before 20:02 UTC on October 15, 2026. Check the backup's timestamp, not its label, and restore both the files and the database. Restoring only files leaves rogue administrators and malicious options behind in the database.
If the only backups were taken after the tainted update arrived, they contain the backdoor. Skip to step 2.
Step 2: Remove the infected component completely
Deactivating a malicious plugin is not enough. Delete the entire plugin folder so none of its code can load again, then remove any database entries the vendor has identified.
In the Rank Math case that means deleting the whole rank-math-pro folder and the wp_options rows named _uf6qdn2hmm, t8krdk990phb and _np5pvf754c. Ask your host or network team to block outbound traffic to the attacker's domain at the same time, so anything you miss cannot call home.
Step 3: Hunt for persistence
Backdoors survive cleanups by copying themselves to places the original component never lived. Check each of these:
- Must-use plugins. Anything in
wp-content/mu-plugins/loads on every request and does not appear in the normal plugin list. - Uploads and theme folders. PHP files in the uploads directory, and unexpected PHP in the
inc/,includes/andlib/folders of non-default themes. - Other plugins. Files added to plugins that were not part of the incident.
- Fake core files. Files in
wp-includes/orwp-admin/that are not part of WordPress. - Server configuration.
.htaccessrules that make unusual extensions execute as PHP, such as the.cachetrick used in the Rank Math payload. - Accounts. Every administrator, including ones with plausible names like "support". Rank Math's indicators include emails ending in
@wp-mail[.]net. - Scheduled work. WordPress scheduled events and the system crontab for the web server user and every other user on the host.
- Shell access. SSH authorized keys for every account, and running processes owned by the web server user.
How do you verify WordPress core and plugin files?
Use WP-CLI to compare installed files against the checksums WordPress.org publishes. Any file that does not match, or that should not exist, needs a closer look.
wp core verify-checksums
wp plugin verify-checksums --all
These commands only cover WordPress core and plugins hosted on WordPress.org. Premium plugins such as Rank Math SEO PRO usually have no public checksums, so for those the safe move is to delete and reinstall from the vendor account rather than trust a comparison. Reinstalling core, plugins and themes from trusted sources is the default for any site without a clean backup.
Step 4: Rotate every credential the site could read
Change credentials after the malicious code is gone, never before. If a backdoor is still running, it will read the new values too.
Rotate, at minimum:
- Every WordPress user password, starting with administrators
- The security keys and salts in
wp-config.php, which also logs out every active session - The database user's password, updating
wp-config.phpto match - Hosting control panel, FTP, SFTP and SSH logins
- Payment, SMTP, email and API keys stored in plugin or theme settings
Our piece on why you should rebuild before you rotate credentials explains the ordering in more depth.
Step 5: Reinstall the clean version and watch
Install the fixed release only from the vendor's own account portal. Rank Math says it never emails download links, so treat any message offering one as phishing. For this incident the clean release is 3.0.124.
Then monitor for reinfection for at least a few weeks: new administrator accounts, new PHP files in uploads, and outbound connections from the web server to unfamiliar domains. If indicators come back, something survived the cleanup, and a full rebuild on a fresh host is the next step.
Why does updating the plugin not fix it?
The fixed release only replaces the plugin's own files. Backdoors already copied into other folders, accounts and scheduled tasks stay exactly where they are.
That gap is the reason trojanized updates are so damaging, and it is covered in what is a trojanized software update. It also means the right defense starts before the next incident, with the controls described in why premium WordPress plugin updates need their own controls.