Researchers at Sucuri have published a detailed breakdown of a WordPress backdoor, tracked internally as "SC," that plants itself in at least eight places on a compromised site at once — a hidden loader file, a disguised "drop-in" that WordPress itself trusts and auto-loads, the active theme's code, a copy in the site's must-use plugins folder, and a matching copy in the ordinary plugins folder. Delete any one of these and the backdoor doesn't need to be re-uploaded: whichever copies remain simply rewrite the missing piece on the next page load.
What makes SC unusual is where else it hides. The full payload is also stored, gzip-compressed, inside the site's own database, and — on hosting that supports it — inside a server memory segment that survives even a complete wipe of every file on disk. Sucuri also found the malware checking around twenty public Ethereum blockchain gateways for instructions from a smart contract, a command-and-control channel that's far harder to take down than a single server. There's no single vulnerability behind SC and no CVE to patch; it's a persistence toolkit that moves in after a site is already compromised through a more ordinary route — an outdated plugin, a weak admin password, or a vulnerable theme — and then makes sure a quick cleanup doesn't stick.
What this means for your business
If your business runs on WordPress — and a large share of small-business sites do — the practical risk here isn't a new way in, it's a new way to stay in after someone finds a way in. The usual response to "we found malware" is to delete the obvious file and move on. SC is built specifically to defeat that: it can look clean for a day and then reappear, because the copy that reinfected the file you deleted was sitting in the database or in server memory the whole time.
If a site you're responsible for has been flagged for malware before, or a previous "cleanup" didn't fully stop odd behaviour, that's worth a proper look this week rather than another quick file delete: unfamiliar code in wp-content/db.php or wp-content/advanced-cache.php, anything unexpected in the mu-plugins folder (most sites have little or nothing there), and recently added code in your active theme's functions.php are the visible tells. A developer doing the cleanup needs to check the database and ask the host about memory-resident processes too, not just the files — a surface-level fix will look successful and fail within days.
The best defence is the same one that stops most WordPress compromises before persistence ever becomes a question: keep plugins, themes, and WordPress core patched, use unique strong credentials with two-factor authentication on every admin account, and have someone who understands the codebase review the site periodically rather than treating "it still loads fine" as proof it's secure.