Security firm Sucuri has detailed a new WordPress backdoor dubbed SC that can restore itself within seconds of removal by regenerating malicious components from a mesh of files, database entries, and shared memory segments.[1][3][6] The campaign highlights how commodity WordPress compromises are evolving into highly resilient infections that can outlast routine cleanup and evade traditional file-based malware detection.[1][3][6]
Sucuri researchers say they first encountered SC during recent incident response work, where the same backdoor kept reappearing no matter how thoroughly infected files were deleted.[1][6] The infection is identified by SC_ markers injected into PHP and template code and by a configuration-based loader—typically a .user.ini file with an auto_prepend_file directive—that runs malicious PHP before normal requests reach WordPress.[1][2][3][6] From there, the payload fans out across at least eight locations, including duplicate plugins in both the mu-plugins and standard plugins directories, ZIP recovery archives with random names, encoded data in the wp_options table, malicious scheduled tasks, and System V shared-memory segments that hold executable PHP.[1][2][3][6]
Beyond persistence, SC provides full-featured site takeover capabilities, including the ability to hide administrator accounts, harvest active admin session tokens, disable or remove security plugins, and inject browser-side scripts that can skim payment data from checkout pages.[1][2][6] Sucuri describes the architecture as a “self-healing mesh” in which every surviving component can rebuild the others during subsequent requests, creating a circular system with no single point of failure for defenders.[3][6] The malware’s command-and-control infrastructure is reported to use blockchain-based coordination, including Ethereum transactions, to manage configuration and possibly to signal updates, adding resilience against domain takedowns and static blocklists.[2][3][6]
This design turns common remediation steps—such as deleting a suspicious plugin or cleaning an infected theme file—into temporary fixes at best.[1][3][6] Researchers note that if the drop-in plugin copy is removed, an injected theme block can recreate it; if the theme is cleaned, a loader or recovery archive can restore the malware on the next page load; and if all visible files are scrubbed, the backdoor can repopulate them from payloads stored in the database or shared memory.[1][2][3][6] The result is a reinfection loop that can persist through filesystem-only cleanup and even through some hosting-level resets unless all components are neutralized in a tightly coordinated operation.[1][6]
There is currently no public CVE identifier or vendor advisory specific to SC, underscoring that it functions more as a multi-stage backdoor and persistence framework than as a single exploitable vulnerability.[3][6] Sucuri attributes the initial compromise to typical WordPress entry points—such as outdated plugins, themes, or weak admin credentials—but stresses that once SC is installed, its layered persistence mechanisms become the main challenge for defenders.[1][6] The victims observed so far are individual and small-business WordPress sites, but the techniques are broadly applicable across shared hosting environments where attackers can reach configuration files and PHP loaders.[1][2][6]
To eradicate SC, Sucuri advises site owners to first stop the backdoor from executing by replacing the configuration loader’s target file with benign content and then removing the auto_prepend_file directive altogether before attempting further cleanup.[1][6] Only after execution is disabled should responders remove database payloads, malicious options, control settings, scheduled tasks, triggers, and shared-memory segments, followed by deleting both plugin copies, drop-in loaders, recovery ZIPs, and any early-loading PHP files in a single, carefully planned pass.[1][2][6] Cleanup should also trim only the injected code from legitimate themes rather than deleting entire themes, then continue with a full rescan, credential rotation, closure of the original entry point, and hardening via prompt WordPress and plugin updates plus a web application firewall.[1][6]
WordPress administrators are urged to proactively review their environments for inexplicable SC_ markers, unexpected .user.ini files, and unfamiliar scheduled tasks or shared-memory usage as indicators of possible SC infection.[1][2][6] Regular audits of database settings, triggers, and user accounts, combined with continuous monitoring for file changes and anomalous admin sessions, can help detect similar self-healing malware before it entrenches at scale.[1][6] As attackers increasingly adopt mesh-like persistence designs, defenders will need to treat cleanup as a coordinated campaign across configuration, files, databases, and server memory—not just a matter of deleting one malicious plugin.[1][3][6]
References
- WordPress Malware Comes Back After Removal Using a Self-Healing Backdoor
- SC WordPress Malware Rebuilds Itself From 8 Locations and Uses Ethereum for C2
- Malware — Latest News, Reports & Analysis | The Hacker News
- WordPress Security News & Updates – Sucuri Blog
