Places the SC payload lives at once: At least 8 (Source: Sucuri, SC WordPress Malware analysis (October 1, 2026))
Cleanup stops being deletion
Picture a site owner who deletes the malware and checks every file. Seconds later, the backdoor is back. Sucuri's analysts saw exactly this during a recent WordPress cleanup. They named the malware family SC, after the "SC_" markers in its code.
The lesson here is that some infections are systems, not files. Each part can restore the others. In that case, effort does not decide the outcome. The order of removal does.
That changes what a manager should ask after an incident. The question is no longer "did you delete it?" It is "in what order, and what did you clear first?"
How the parts rebuild each other
SC is not one program. It is a set of parts kept on disk, in the database and in server memory. Any surviving part can bring back the rest on the next page load.
Several parts sit where WordPress looks very early. The db.php drop-in holds the full malware inside itself. A drop-in is a file WordPress loads automatically from the wp-content folder. If the main plugin goes missing, db.php writes it back.
The advanced-cache.php drop-in works differently. It runs before ordinary plugins, when caching is on. It does not hold the malware. It hunts for a copy to restore. It checks five places in turn, and the last one is the database.
The active theme is also infected. Sucuri found a block added to the bottom of its functions.php file. That block rewrites the plugin whenever it disappears.
The main malware is installed twice. One copy is a must-use plugin. That type loads on its own and stays out of the normal plugin list. The other is an ordinary plugin.
The ordinary copy comes with a settings page. A casual reviewer could take it for a real caching tool.
Two more triggers exist. A .user.ini file has an auto_prepend_file line. It tells PHP to run a loader before every request, even one that never reaches WordPress. Scheduled tasks can also reinstall the malware on a timer.
Copies outside the file system
Sucuri calls this the key lesson: persistence is not limited to files. The team recovered live payload copies in three non-file locations. Two of them are a database row and a shared-memory segment.
The database row holds the whole payload. That is why a perfect file cleanup still fails. The first page request after the cleanup triggers a rebuild from that stored copy.
Shared memory sits in RAM. Deleting files does not clear it, and neither does a database cleanup. On shared hosting, another account can own that segment.
Sucuri also saw database triggers in related SC variants. A trigger is a rule stored inside the database. Here, it recreates an administrator account when a new record is added. Deleting the account is pointless until the trigger is gone.
What the malware does once it runs
First, it hides. It removes its own entry from the plugin list and from update checks.
Next, it creates a hidden administrator and forges login cookies for that account. The operator can then sign in without a password.
It also gathers site details and the current administrator session tokens. It encrypts them and sends them to its controller.
The reply can carry new PHP code and front-end JavaScript. On a store, Sucuri notes, that JavaScript enables checkout skimming. The reply can also list security plugins to deactivate and delete.
These gateways carry the commands. The malware does not rely on one server. It reads instructions from a smart contract through public Ethereum gateways. Blocking the one seen in traffic leaves the others as backups. Sucuri says the whole set must be blocked together.
The order that works
Sucuri's cleanup steps run against instinct. The first job is to stop code from running. Empty the loader file that auto_prepend_file points to, so it is inert. Then remove the directive.
The order matters because PHP remembers that path for up to 300 seconds. If the file vanishes while PHP still remembers it, every PHP request on that account fails.
Next, clear the copies outside the files: the database row, the memory segment and the control options. After that, deal with the timers and database rules. Clear the malicious cron hooks, and check for triggers that recreate an administrator. Only then delete the hidden account.
Only after that should the files be cleaned, in a single pass. Finally, rescan and watch for files that return. A returning file means a copy survived or the entry point is still open.
What this report does not tell us
This is one analysis of one malware family. It does not say how many sites carry SC. The excerpt we reviewed does not explain how the attackers first got in.
Sucuri says only that most compromises it handles use known, already-fixed flaws. Sucuri also sells cleanup services. Keep that in mind when weighing its advice.
Questions to put to your team
Does our incident process cover the database, memory, scheduled tasks and triggers, or only files? Who confirms the order before anything is deleted?
Can we list administrators without the dashboard user screen? SC hides its account from that screen. Do we know which drop-ins, db.php and advanced-cache.php, belong on each site?
Does anyone watch for web servers contacting public Ethereum gateways? Sucuri lists this among the signs of infection. After cleanup, do we rotate every credential the attacker could have touched, as the report advises?
A cleanup succeeds when the site stays clean after the next page load. Files that merely look right prove nothing.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Sucuri.
