Sucuri published an analysis on 30 September 2026 of a WordPress infection it calls SC, after the SC_ markers left in the injected code. The interesting part is not what the backdoor does once it runs. It is that removing it, in the ordinary way, repairs it.

Eight places on disk, and three off it

The payload is not a file. It is a set of components that each hold a copy of the others.

On disk, Sucuri lists a .user.ini carrying an auto_prepend_file directive, a visible shim in wp-content, a hidden dot-prefixed loader, a db.php drop-in, an advanced-cache.php drop-in, an injection in the theme's functions file, a payload in mu-plugins, and an ordinary-looking copy in the plugins folder.

Off disk, it also lives in the database options table, in System V shared memory, and in scheduled cron hooks, with database triggers to restore what is deleted.

Sucuri's description of the result is two sentences long and explains the entire incident: "Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it."

Why ordinary cleanup makes it worse

Most WordPress cleanups are iterative. A scanner flags a file, someone deletes it, the site is checked, another file is flagged tomorrow.

Against a mesh, that process is not slow — it is counterproductive. Every partial removal is a trigger: the remaining components see a missing sibling and rewrite it, sometimes with a new name in a new location, so the next scan finds something unfamiliar and the operator concludes they are facing a new infection. The site is never clean and the defender is learning the wrong lesson.

The prepend directive is the piece to disable first. While auto_prepend_file is in force, attacker code runs before every PHP request on the site, including the request that is deleting its files. Sucuri's cleanup order starts there for that reason: neutralise the prepend, then clear the off-disk copies in the database and shared memory, then the cron entries and triggers, then the hidden administrator, and only then remove the files — all in one pass.

Command and control with no domain

The second design decision is the channel. Instructions are fetched through roughly twenty public Ethereum RPC gateways, using smart-contract method selectors to read the operator's current configuration.

That removes the usual choke point. There is no command server to seize, no domain to sinkhole, no single address to block: the data sits in a public chain that anyone can read, and the gateways are ordinary infrastructure that plenty of legitimate software also talks to. Block one and nineteen remain. Taking the content down is not available at all, because a blockchain is the one storage medium built so that nobody can delete from it.

What it does while it is there

Once running, the backdoor hides its own plugin from the admin screens, creates hidden administrator accounts and forges the authentication cookies to use them, strips out security plugins, injects JavaScript for payment skimming, and exposes a parameter that lets the operator confirm the site is still theirs. On every request, it checks itself and rebuilds whatever is missing.

For a shop, the skimming is the loss that matters, and it is silent: the checkout keeps working, the orders keep completing, and the card details are copied on the way through.

The backup will put it back

The instinct after an infection like this is to restore from a backup, and on this one that is a trap worth naming.

The components live in the places a backup is designed to capture: ordinary files under the web root, a mu-plugin, the theme, and rows in the database. A restore from any point after the first compromise brings the mesh back whole. A restore from before it, if one exists, also discards every order, comment and post since.

The shared-memory copy adds a second trap. It does not survive a restart of the PHP processes, which sounds like good news until you notice the consequence: a cleanup that looks complete can be undone by a component that was only in memory, and a reboot can equally make a piece of the infection vanish from the evidence before anyone has catalogued it.

The .user.ini piece is what makes all of this portable. Shared hosting with PHP-FPM reads that file per directory, so the attacker does not need to touch the server configuration, and the same technique works on most commodity hosting a small shop is running on.

What to do

  • Do not clean this iteratively. Inventory every component first, then remove in one pass, in Sucuri's order: prepend directive, database and shared-memory copies, cron and triggers, hidden admins, files.
  • Look in the places that are not plugins: .user.ini, db.php, advanced-cache.php, mu-plugins, the active theme's functions file, the options table, and PHP shared-memory segments.
  • Treat outbound requests to Ethereum RPC gateways from a web server as an alert on its own. A content site has no reason to talk to a blockchain node.
  • After cleanup, rotate everything: administrator passwords, database credentials, salts and keys in the configuration, and any payment-gateway secrets the site held.
  • Watch for recreation for several days. If a file comes back, the inventory was incomplete, not the removal.

What is not established

  • How initial access is obtained. The analysis describes persistence, not the way in.
  • How many sites are affected.
  • Who operates it, and whether the skimming and the backdoor are run by the same group.
  • Whether the contract addresses used for configuration have been rotated since publication.