Self-Healing WordPress Malware: The SC Backdoor That Rebuilds Itself After Cleanup

Self-healing WordPress malware is no longer a theory. Researchers at Sucuri have described a family they call SC, after the “SC_” markers it leaves in injected code, and it is built so that cleaning it up does not work. It keeps copies of itself in at least eight places, and each copy can rebuild all the others.

That design matters to any business that has ever paid someone to “clean” a hacked website, only to watch the problem return a week later.

What Sucuri found

The analyst behind the write-up, Gabriel Barbosa, documented SC during a recent site cleanup. His summary is blunt: “Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it.”

The malware spreads across ordinary-looking parts of a WordPress install:

• A .user.ini file that tells PHP to run a hidden loader before every request.
• Two loaders in wp-content, one visible and one dot-prefixed, both with a random hex name.
• The db.php and advanced-cache.php drop-ins, which WordPress loads very early.
• A block appended to the active theme’s functions.php.
• A fake plugin called hyper-engine-kit, stored twice: once as a must-use plugin and once as a normal one.

Those eight points are only the files. The payload also sits in a database options row, in a System V shared-memory segment, and in randomly named ZIP bundles. Scheduled cron hooks trigger a redeploy. One surviving copy is enough to restore everything on the next page load.

Why self-healing WordPress malware beats a normal cleanup

Most cleanups follow the same pattern: find the bad files, delete them, scan again. SC is designed around that pattern. The advanced-cache.php drop-in checks five sources in turn (the two plugin copies, shared memory, the ZIP bundles and the database) and rebuilds the plugin from whichever one still exists.

The shared-memory copy is the nasty one. It lives in RAM, not on disk, so a file scan never sees it. A restore from last night’s backup does not touch it either. Sucuri also notes that on shared hosting, ownership of the segment can make it awkward to remove.

Timing adds another trap. PHP caches the auto_prepend_file setting for around 300 seconds, so the loader can keep running after you think you have removed it.

How the backdoor takes orders

The operators do not rely on one command server that defenders could block. According to Sucuri, SC carries roughly twenty public Ethereum gateway addresses and uses smart-contract calls to find its instructions. Blocking a single domain does nothing, and the traffic looks like ordinary crypto lookups.

Once running, the backdoor can do real damage. It hides itself from plugin lists and update screens. It fingerprints the site, creates or adopts a hidden administrator account, and forges login cookies. It can also push JavaScript to the front end for checkout skimming and delete security plugins.

For a shop taking card payments, that last pair is the worst outcome. A skimmer on a checkout page can run for weeks before anyone connects it to fraud reports.

How it gets in is still unclear

Sucuri does not say how the infections start. The usual routes apply: a vulnerable plugin, a stolen password or a compromised supply chain. The Hacker News, which covered the research, also pointed to a wpForo Forum SQL injection flaw (CVE-2026-1581) seen in related activity, but the link to SC is a possibility, not a confirmed cause.

That uncertainty is itself useful. If the entry point is unknown, then the same hole is probably still open after you clean up.

What to check on your own sites

None of this needs special tooling to start. A practical first pass looks like this:

1. Look for auto_prepend_file in .user.ini, php.ini and .htaccess.
2. Open db.php and advanced-cache.php in wp-content. If you do not use an object cache or page cache plugin, an unexpected file there is a red flag.
3. List administrator accounts and question any you do not recognise, including accounts that do not appear in the users screen but exist in the database.
4. Check for a plugin you did not install in both the plugins and mu-plugins folders.
5. Ask your host to run ipcs -m and look for shared-memory segments containing readable PHP.

If you find a hit, the order of cleanup matters. Neutralise the prepend loader first, then clear the database row and shared memory, then the cron hooks and the hidden admin, and only then remove files. Rotate every credential afterwards, and watch for the files reappearing. If they do, an off-disk copy survived.

The wider lesson for testing

Self-healing WordPress malware is also a good argument for monitoring that does not rely on the site itself. A tool that runs inside the infected install can be filtered or switched off by the malware. Checks from outside, and file integrity checks run from the server, are harder for it to hide from.

SC is a reminder that a clean scan proves less than most people assume. Scanners look for known bad files. They do not tell you how an attacker got in, or whether the door is still open. A scoped penetration test works from the attacker’s side: it looks for the weak plugin, the exposed login or the over-permissive hosting set-up that let the malware land in the first place.

We covered similar ground in our piece on third-party plugin risk, where a patch sat unapplied for months. If you want a second opinion on a site that keeps getting reinfected, you can get in touch with the Aardwolf team.