Imagine cleaning a mould infestation by wiping down the walls — only to find it's also living in the floorboards and the ventilation system. That's roughly the situation researchers at Sucuri are describing after dissecting a WordPress compromise they've dubbed "SC": a backdoor that survives cleanup by maintaining three separate footholds simultaneously, and uses them to resurrect whichever one you manage to remove.

The malware plants itself in the site's file system, embeds itself in the WordPress database, and exploits PHP shared memory — a low-level caching mechanism most site owners don't even know exists. Each of those locations acts as a recovery node. Delete the file-based payload? The database copy notices and rewrites it. Scrub the database? Shared memory kicks in. Sucuri calls it a "self-healing mesh," which is a polite way of saying it's specifically engineered to outlast standard incident response.

Why this one is different. Most WordPress malware relies on a single persistence mechanism — usually a rogue plugin, a modified theme file, or a backdoored core file. The attacker bets that defenders won't look too hard. SC doesn't take that bet. It assumes detection and plans around it. That's a meaningful step up in operational sophistication for what is, ultimately, commodity WordPress compromise.

The trigger markers are "SC_" strings injected into content — useful for detection, but only if you know to look. The final payload the backdoor protects hasn't been fully disclosed, which is probably the most alarming part: we know the delivery mechanism is clever, but not yet what it's ultimately delivering.

Who's at risk. WordPress powers roughly 43% of all websites globally, and that figure holds in Australia where it underpins a huge proportion of small business, media, and government adjacent sites. Shared hosting environments are particularly exposed because PHP shared memory persists across requests and tenants may not be cleanly isolated. If you're running WordPress on shared hosting, or managing it for clients, this warrants a proper audit — not just a plugin scan.

What to actually do. Standard advice like "run a security plugin" is insufficient here. You need to check the database directly for injected content (look for SC_ markers in wp_posts and wp_options), audit your PHP shared memory state if your host exposes that, and verify file integrity against known-good checksums. If you find one component, assume all three are present.

The broader signal. Persistence is the new sophistication. Attackers are spending less energy on initial access — WordPress is trivially compromised via outdated plugins — and more energy on staying put after defenders respond. The SC backdoor is a case study in what happens when someone applies proper engineering discipline to what used to be a smash-and-grab exercise.

Watch for Sucuri and other researchers to publish detection rules and indicators of compromise in coming days. In the meantime, the practical advice is straightforward: if a WordPress site you're responsible for shows any unexplained behaviour, treat it as a full compromise and clean accordingly.