The "SC" WordPress Backdoor Rebuilds Itself After Cleanup: Where It Hides and How to Remove It

You delete an infected file, and a few minutes later it is back. Sucuri researcher Gabriel Barbosa described a backdoor called "SC" on October 1, 2026 that behaves exactly like this. He found it during incident response in September. According to Sucuri, it is "a circular system with no single point you can remove to stop it." Below we explain how it works and how to clean it.

Where it hides

Sucuri talks about eight persistence locations. The sources we read list seven of them:

1. A .user.ini file that automatically loads a PHP loader.
2. Hidden PHP files spread across wp-content.
3. An encoded payload in the database. According to reports, a full copy sits in a row of the WordPress options table under a random name.
4. Code injected into the theme's functions.php.
5. Malicious must-use plugins (mu-plugins). They run on every page load and do not show up in the normal plugin list.
6. Malicious regular plugins.
7. Server shared memory segments, on servers that support them.

Why normal cleanup fails

Each part rebuilds the others. Delete the plugin and a drop-in file rewrites it. Delete the drop-in and the theme rewrites it, and so on. The copy in the database restores the files after you delete them, and the copy in shared memory survives both a file cleanup and a database cleanup. According to one report, on shared hosting such a segment may even belong to a different account, so the hosting provider has to clear it.

One caveat: Sucuri did not find out how the sites were first infected. Typical entry points are vulnerable plugins and themes, weak admin passwords, a compromised vendor or unsafe file uploads. Shared memory comes from reports of a single case, so do not assume every WordPress infection works this way.

How to clean it

Sucuri has not published a ready list of steps. The advice is: a full review (files, database, theme code, plugins, server memory) and removal of all persistence points at the same time, not one by one. In practice that means:

1. Take a copy of the whole site and database for analysis. Keep the server logs.
2. Take the site offline during cleanup (maintenance mode or a block at server level), so nothing rebuilds files while you work.
3. Compare files with a clean install. Reinstall WordPress core, the theme and plugins from official sources. Check .user.ini, mu-plugins, functions.php and unknown PHP files in wp-content.
4. Review the database: look in the wp_options table for long, encoded values with random names. Check cron jobs too.
5. Clear the opcode cache (OPcache) and ask your host to check and clear shared memory segments.
6. Change all passwords and keys: WordPress administrators, database, FTP/SSH, keys in wp-config.php.
7. Find the entry point. Without it, the infection comes back. Check which plugins and themes were vulnerable, for example Bricksforge (CVE-2026-85097). Also update PHP if your server is exposed to the PHP2Shell flaws.

If this is not your specialty, hand it to an incident response team. Cleaning "piece by piece" is the most common reason malware comes back.

How to notice it earlier

The most common sign is a file that returns after you delete it. It is also worth checking regularly whether wp-content/mu-plugins and the site root contain files you did not add, and whether the theme changed without your knowledge. More on symptoms: How to Detect Malware on Your WordPress Site.

Sources

• Daily Security Review: Self-Healing WordPress Backdoor Defies Standard Removal
• The Hacker News: WordPress Backdoor Rebuilds Itself After Cleanup
• RS Web Solutions: WordPress Backdoor Reconstructs Itself Post-Cleanup