If your WordPress site has ever been hacked, you probably know the cycle. A security plugin found something. The bad files were deleted. The site looked normal again, and everyone relaxed. Three days later it was serving spam links, or redirecting visitors on phones, or sending email you never wrote. The explanation you were given, politely or otherwise, was that the original hole was never closed, so they got back in. Sometimes that is true. This month, a researcher showed that sometimes it is not true at all. Nobody got back in. A WordPress backdoor meant they never left.
Eight copies, each one rebuilding the others
On 1st October, Gabriel Barbosa, a researcher at the security firm Sucuri, published an analysis of a WordPress backdoor his team has codenamed SC, after the markers it leaves in infected code.[1] A backdoor is exactly what it sounds like: a hidden way back into your site that an attacker installs once they are in, so they never need the original hole again.
What makes this one worth your attention is where it lives. The payload, the code that actually does the attacker’s work, keeps itself in at least eight places at the same time, spread across your site’s files, its database and the server’s working memory. Sucuri calls the result a self-healing mesh, and the important word is mesh: every copy can rebuild all the others.[1]
The hiding places are worth listing, because they are precisely the places nobody looks:
- A settings file that PHP reads before your site even starts, called
.user.ini - Two loader files in
wp-content, one visible and one hidden - A file called
db.php, which WordPress treats as a legitimate way to extend its database handling - A fake cache file, posing as part of your site’s speed tooling
- Your active theme’s
functions.phpfile - A must-use plugin, which is a special kind of plugin WordPress loads automatically and never lists on your ordinary Plugins page
- A matching ordinary plugin, wearing the same name
And then the eighth, which deserves its own paragraph. On many servers the payload also sits in shared memory, meaning the server’s working memory rather than any file on disk. You can delete every suspicious file, clean the database, and the copy in memory is still running, quietly writing everything back.[1]
Why the clean-up keeps failing
Now the cycle makes sense. You delete the hidden loader, and the database copy writes it back. You clean the database, and the must-use plugin restores it. You replace the theme, and the cache file is still holding a copy. You cannot win that race by hand, and neither can a plugin that scans files, because two of the eight copies are not files in any normal sense. Running a scanner, seeing zero results and declaring the site clean is not evidence of anything here. Keep running the scanner; it still catches the ordinary infections, which are most of them. Just do not let a clean result close the file on this one.
One more piece of standard advice fails too. The usual move after an infection is to block the malicious domain the malware talks to. This family does not have one: Sucuri describes it taking its instructions through lookups on a public blockchain rather than from a fixed address, so there is nothing lasting to block.[1]
How does it get in? Boringly. Sucuri lists the ordinary routes: a plugin or theme with a known flaw that never got its update, a weak or reused password, a compromised add-on from the supply chain, or an upload form that accepts whatever it is given.[1] We have written about why updates cannot wait and what upload forms let in, and this is where those roads lead.
How worried should you be?
Here is the context that matters, and it changes the tone of everything above. This is not a flaw in WordPress. Nothing in this article breaks into a site on its own; SC is what an attacker installs after they are already in, and the ways in are the ordinary ones listed above, every one of them preventable with the unglamorous basics. A site on current versions, with current plugins, strong passwords and no upload form it does not need, is very unlikely ever to meet this thing. WordPress runs a large share of the web and runs it well when it is looked after. The reason to know about SC is not to fear WordPress. It is to know what proper recovery looks like if the bad day ever comes, because the folk remedy, delete the bad files and move on, is the one thing we now know does not work.
What actually works
Two things, and it is worth being plain about both.
The first is restoring from a backup taken before the infection. Not the newest backup, the right one: the newest copy that predates the first symptom. That distinction matters because symptoms usually start weeks before anyone notices them, which is also the argument for keeping backups further back than feels necessary. A restore from a clean point in time removes all eight copies at once, because it does not negotiate with any of them.
The second is a rebuild, for when the backup window has closed. If every backup you hold already contains the infection, the honest answer is a fresh WordPress installation, your content moved across deliberately, every plugin reinstalled from source, and every password and key changed. That is real work. It is sometimes the right answer, and anyone who promises you a quicker certainty on a site this family has touched is selling the feeling rather than the fix.
Sucuri’s own remediation advice reflects how deep this goes: a full audit of files and the database, a check of the server’s shared memory segments, and a review of WordPress’s scheduled tasks for entries that should not be there.[1] That is specialist territory, and there is no shame in it being somebody else’s job.
Here is where our hosting stands on this. Every plan we sell includes daily automated backups, stored off-site and away from the live server, so an infection on the site cannot reach into them, with one-click restore when you need it. Active exploit and malware scanning runs across the sites we host, on every plan, built to notice code arriving where no code should be. And when a customer reports a hacked site, that is a conversation with a person, not a knowledge-base link: we help you find the right restore point, work out what let the attacker in, and close it behind them. On our managed WordPress hosting, the updates that keep the common doors shut are applied for you automatically.
The clock this runs against
One last fact for context rather than alarm. Microsoft’s 2026 Digital Defense Report, published the same day as Sucuri’s research, says AI tooling has compressed attackers’ post-compromise work, the stealing and spreading that happens after a break-in, from days to minutes.[2] The time available to notice an infection is shrinking in the same season that infections are getting harder to remove. The combination is the argument for the unglamorous things this article keeps coming back to: updates that happen on their own, backups that reach back further than you think you need, and somebody whose actual job is to look.
If your site was cleaned once and you have never been quite sure it was really fixed, that is exactly the doubt we would rather you brought to us than sat with. Ask us for a site health check: what is on the server, how far back your backups go, what version everything runs, and whether anything looks wrong. It is free, and either answer is useful.
Related reading
- WordPress 7.1.2 was attacked the same day it shipped. Here is what to check.
- WordPress backups and recovery: getting it right
Sources
- WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database, and Shared Memory, The Hacker News, 1st October 2026, reporting Sucuri research by Gabriel Barbosa.
- Microsoft: AI Cuts Post-Compromise Attack Time to Minutes, Infosecurity Magazine, October 2026, on the Microsoft 2026 Digital Defense Report.
