Sucuri published research on September 30, 2026 describing a WordPress backdoor, nicknamed SC, that survives a normal cleanup by hiding in eight places at once: five separate files, a database options row, a scheduled task, and a shared memory segment on the server itself. Delete the obvious plugin file and the other seven copies quietly rebuild it. The malware was found during real incident response work, not a lab test, and it talks to its command infrastructure through public Ethereum RPC gateways instead of a server an investigator could just block.
What Sucuri Found
Security analyst Gabriel Barbosa named the backdoor SC after markers left in the injected code. According to Sucuri’s writeup, the payload lives across a .user.ini file that silently auto-loads a hidden loader, a visible shim at wp-content/c1b12371.php paired with a hidden version of the same file, the wp-content/db.php and wp-content/advanced-cache.php drop-ins WordPress trusts without question, an injected block in the active theme’s functions.php, and a copy of the backdoor installed twice, once as a must-use plugin and once as a regular one, under the name hyper-engine-kit.
Each of those locations can read a compressed, base64-encoded copy of the full payload out of a randomly named row in the wp_options table, or out of a System V shared memory segment that lives in RAM and outlives both a file wipe and a database cleanup. Database triggers quietly recreate hidden administrator accounts if they get deleted. That is why, as Barbosa put it, cleaning one location fails until every copy is purged in the same pass.
Why It Is Hard to Block
The command-and-control layer is the more unusual part. Instead of phoning home to a domain a host or firewall could blacklist, SC reads instructions from a smart contract through roughly twenty public Ethereum RPC gateways. Blocking the one gateway seen in a log leaves the other nineteen working fine, and none of them look unusual to a web host, since they are the same infrastructure crypto wallets use all day.
What WordPress Site Owners Should Actually Do
Sucuri’s own guidance, and the broader pattern confirmed by The Hacker News’s coverage of the same research, comes down to a few concrete steps rather than a single file delete:
- Neutralize the
auto_prepend_filedirective in.user.inibefore touching anything it points to, or the loader just reloads itself mid-cleanup. - Check the
wp_optionstable for unfamiliar, randomly named rows holding compressed data, not just the usual suspects. - Remove all eight components in a single pass rather than one at a time, since surviving copies will simply rewrite the ones already deleted.
- Audit scheduled tasks, database triggers, and the admin user list afterward, since this is exactly where SC hides its recovery hooks.
- Treat any file reappearing after cleanup as a sign the job is incomplete, not as a new, unrelated infection.
This is also a reasonable argument for not treating WordPress security as a one-time fix. A site that gets this kind of deep, multi-location compromise usually got in through something ordinary, an outdated plugin, a weak admin password, a forgotten staging copy left public, well before the backdoor itself showed up. Regular WordPress maintenance and development work that keeps plugins current and reviews the admin user list on a schedule closes most of the doors this kind of malware walks through in the first place.
It is also a reminder that WordPress’s own ecosystem has been tightening the other side of this problem lately. Automatic update gates like the one covered in WordPress.org’s new auto-blocking of high-risk plugin updates are aimed at the supply side. Research like Sucuri’s is what catches what gets through anyway.
