WordPress Backdoor That Rebuilds Itself: How to Clean It Properly

If you have ever cleaned a hacked WordPress site, deleted the bad files and watched them come back the next day, this post is for you. Security firm Sucuri has described a WordPress backdoor, which it calls SC, that is built to do exactly that. The useful news is that the way to deal with it is clear, and a calm, ordered clean-up works.

My last posts covered a poisoned Python package and the PHP2Shell flaws. This one stays closer to home for anyone who runs a WordPress site.

What Sucuri found

Sucuri came across SC while working on incident-response cases in September 2026 and published its research on October 1. The headline feature is persistence. The malware keeps copies of itself in at least eight places across files, the database and, on compatible servers, shared memory. If one piece is deleted, the others quietly put it back.

According to the write-up, those places include:

• a .user.ini file that loads a PHP file before every other script
• hidden PHP files inside wp-content
• an encoded payload stored in the database
• code injected into a theme’s functions.php
• a must-use plugin, which runs on every request and does not show on the normal Plugins screen
• a regular plugin
• shared memory segments

What it can do

Once it is running, the reported abilities are practical ones for an attacker: creating a hidden administrator account, injecting JavaScript into pages, running arbitrary PHP, and turning other plugins off or deleting them. It also hides itself from the plugins list and from update checks.

For instructions, it uses the Ethereum blockchain rather than a single server. That matters because there is no one domain to block or take down. It also means the fix has to happen on your site, not at the attacker’s end.

How sites get infected

This is worth being clear about: Sucuri did not say how SC first reaches a site. The usual routes for this kind of malware are vulnerable plugins or themes, weak admin passwords, compromised supply chains and insecure upload features, but none of these was confirmed as the route SC used. Because there is no single software flaw behind it, there is also no vendor patch to install. The defence is good housekeeping plus a thorough clean-up.

Why deleting files is not enough

Sucuri’s point is that cleaning one layer leaves enough behind for the rest to regenerate. If you clean every file on disk but leave the database payload, the next page load restores the files. So the clean-up has to remove all the layers together, and it should come before you change passwords and keys, otherwise the malware can simply capture the new ones.

A calm clean-up plan

This follows Sucuri’s guidance to review files, database, theme code, plugins and server memory in one pass, and borrows the ordering suggested in a clean-up guide from security vendor Monarx. If the site matters to your business, a professional incident responder is a good investment.

1. Contain. Put the site in maintenance mode or switch PHP off for it, take a full copy of files and database for evidence, and treat every logged-in admin session as untrusted.
2. Find the loader. Check mu-plugins, .user.ini and .htaccess for auto_prepend_file lines you did not add, plus db.php, advanced-cache.php and your theme’s functions.php for code you do not recognise.
3. Remove everything together. Delete the hidden files and injected blocks, the malicious plugin entries, and the stored payloads in the database options table. Restart PHP so nothing is served from memory.
4. Check users. Look for administrator accounts you did not create, including ones that do not appear on the Users screen but exist in the database. Remove them and end all sessions.
5. Check neighbours. On shared hosting, look at other sites in the same account for the same files.
6. Then change secrets. Reset hosting, database and WordPress passwords and refresh the keys in wp-config.php only after the site is clean.
7. Watch. Re-enable the site and check for returning files over the next few days.

Habits that make reinfection less likely

• Keep core, plugins and themes updated, and remove anything you no longer use.
• Avoid nulled or pirated plugins, which are a common hiding place for backdoors.
• Use unique admin passwords with two-factor sign-in.
• Limit who can write to wp-content, and consider turning off in-dashboard file editing.
• Keep off-site backups from before any problem, so a restore is possible.
• Add a file-integrity or malware scanning plugin, and read its alerts.

A short checklist for this week

1. List every plugin and theme on your sites and remove the unused ones.
2. Check the mu-plugins folder for files you do not recognise.
3. Look at your administrator list for names you did not add.
4. Turn on two-factor sign-in for every admin.
5. Confirm you have a recent off-site backup you can restore.

Small, regular checks like these take minutes and make a real difference. If you would like a second pair of eyes on a WordPress site, you can find me at expertwebdeveloper.in and read more security notes at growsmartwithai.com.

This post is also available on dev.to, Medium and Substack.

Sources: The Hacker News · Daily Security Review · Monarx