If you’ve ever cleaned up a hacked WordPress site, you know the drill. Find the bad file, delete it, change some passwords, breathe out. Now imagine doing all that, refreshing the page, and watching the malware quietly grow back like nothing happened.

That’s what security researchers at Sucuri describe in a new write-up on a backdoor they’ve named SC, after the “SC_” markers they found in the injected code. Sucuri’s own description is a “self-healing mesh,” and after reading through the details, I think that’s fair. The story was also covered by The Hacker News on October 1.

One backdoor, eight hiding spots

Most malware has a main file you can point at. SC doesn’t. According to Sucuri, the same payload lives in at least eight places across files, the database and shared memory, and each one is able to rebuild the others.

Here’s roughly what’s involved:

• A .user.ini file that tells PHP to run a loader before every request in that directory tree.
• Two loader files in wp-content (one visible, one hidden with a leading dot) that locate or rebuild a fake plugin.
• db.php, a WordPress drop-in that carries the whole payload in compressed, encoded form and redeploys the plugin whenever it goes missing.
• advanced-cache.php, another drop-in that can restore the plugin from five different sources, including shared memory and the database.
• A theme file (functions.php in a theme called khorshidi) that does the same job as db.php.
• A fake plugin called hyper-engine-kit, installed twice: once as a must-use plugin and once as a normal one. This is the actual malware.

The code is also scrambled with a substitution cipher and has no readable function names, so skimming files for something suspicious won’t get you far.

The part that surprised me: shared memory

On servers that support System V shared memory, SC stashes a copy of the payload in a memory segment under a fixed key. Because that lives in RAM, deleting files doesn’t touch it, and neither does cleaning the database. Sucuri notes that on shared hosting that segment can even belong to a different account on the same server.

On top of that, the malware registers cron hooks, and system cron (not visitor traffic) triggers redeployment on a schedule. So even a quiet site with no visitors can reinfect itself.

What the backdoor actually does

Whichever copy launches, the behavior is the same. It hides itself from the admin plugins screen and from update checks. It fingerprints the infected site and fetches more payloads. It creates a hidden administrator account. And it talks to its command-and-control server through the Ethereum blockchain, which is a clever way to hide traffic inside legitimate infrastructure.

For the attacker, that adds up to full control of the site. They can run PHP code, inject JavaScript to target your visitors (think payment skimmers), and switch off or delete specific plugins.

Related: wpForo is being exploited too

The same coverage mentions a separate problem. The wpForo Forum plugin has an unauthenticated SQL injection flaw, CVE-2026-1581 (CVSS 7.5), affecting every version up to and including 2.4.14. Telemetry from Previdian shows fewer than 20 exploitation attempts since July 3, 2026, from five IP addresses in Bulgaria, Switzerland, France, the US and Yemen.

That’s a small number, and nothing links it to SC. But it’s a good reminder that known plugin bugs are a common way in. If you run wpForo, check your version and update.

What I’d do if I ran WordPress sites

This is general hardening advice rather than an official cleanup procedure, so check the Sucuri write-up for specifics.

1. Update everything. Core, plugins and themes. Remove anything you don’t use, especially abandoned plugins.
2. Look in the odd places. Check for .user.ini files, unexpected db.php or advanced-cache.php drop-ins (when you don’t use caching), and anything in mu-plugins that you didn’t put there.
3. Audit your admin users. A hidden administrator won’t always show up in the usual list, so compare against the database directly.
4. Don’t clean file by file. If you find SC, restoring from a known-clean backup or rebuilding the site is safer than chasing copies. Ask your host to check for leftover shared-memory segments and cron entries too.
5. Rotate every credential. WordPress logins, database passwords, SFTP and hosting accounts, and API keys.
6. Lock down uploads and file editing. Block PHP execution in upload directories and turn off the built-in file editor.

Sources: The Hacker News (Ravie Lakshmanan, Oct 1, 2026), Sucuri research by Gabriel Barbosa, Previdian telemetry on CVE-2026-1581.