Sucuri says the SC WordPress backdoor lives in at least eight places. Its own report names eleven

Eight places by the headline, eleven by the list

Sucuri's report on the SC WordPress backdoor says the malware lives in "at least eight places at once, spread across files, the database, and shared memory". Its own table lists eight, and every one of them is a file. The section after the table names three more places that are not files: a database row, a shared-memory segment and scheduled tasks. That makes eleven (our count). A cleanup that removes the eight files and nothing else leaves 3 of the 11 places, or 27 per cent, and Sucuri says any one of those three will rebuild the whole set on the next request.

What that does not establish. It does not say how many sites carry SC, when the first was seen, who runs it or how it got in. It is one analyst's account of one compromise. It tests no cleanup product, and it publishes no file hash, no domain and no smart-contract address. Its overview and its table also count differently, which is why the eleven is ours and not Sucuri's.

This briefing sets out what Sucuri states and omits, adds a second vendor report that looks related and is not said to be, and ends with a cleanup order for UK site owners and agencies. It stays at defender level: places to look, no code and no loader content. Earlier briefings cover the WordPress core include flaw patched twice in five days and its exploitation. The same lesson on another product, that an update is not a cleanup, is in the NetScaler briefing.

What Sucuri published, and what it left out

The post comes from Sucuri, a website security vendor. The author is Gabriel Barbosa, whom Sucuri describes as a security analyst who joined in 2015. He writes that SC turned up "during recent website cleanup work", on a site where the same backdoor kept returning "within seconds of every removal". Sucuri names the family after "SC_" markers in the injected content. The Hacker News covered it on 1 October and adds nothing technical about SC beyond Sucuri's post. It does add an unrelated item, taken up below.

What Sucuri's post states and does not state about SC. Read in full on 1 October 2026. Wording in quotation marks is the post's own.

Topic	Stated	Not stated
Who and when	Gabriel Barbosa, post dated 30 September 2026. Found "during recent website cleanup work".	When the first infection was seen, how many cleanups, or any date range.
Scale	One infection analysed. Example names: a loader c1b12371.php, a theme khorshidi, a plugin hyper-engine-kit.	How many sites, hosts, countries or sectors. Sucuri says several file names vary from site to site.
Where it hides	Eight file components. Off disk: a database options row, a System V shared-memory segment, scheduled tasks. Triggers in "related SC variants".	The shared-memory key, the option name and the cron hook names (random), the trigger definitions.
How it got in	Nothing specific. A durable fix "closes the original entry point".	Any CVE, plugin, theme, stolen credential or supply-chain link. The Hacker News says the delivery method is not known.
What it does	Hides itself, reads instructions from a smart contract via public Ethereum gateways, fingerprints the site, can inject JavaScript, install PHP, delete security plugins, create a hidden administrator and forge login cookies.	Any observed skimming or victim. The post says injected script "enables checkout skimming" on a store, not that it did.
Indicators	Nine behavioural indicators, from marker strings to outbound requests to public Ethereum gateways.	A file hash, domain, IP address, contract address, gateway list or option name.
Cleanup	Six steps in a set order, and a closing call to rotate "every credential the attacker could have touched".	A test of any named cleanup product, which credentials, whether to restart PHP, how long to watch.
Actor and motive	The operator can take control of the site and fetch new code.	A name, an attribution, a motive, or a link to any other report.

Commercial interest. Sucuri sells website firewalls, monitoring and hacked-site cleanup, and the post closes with an offer of a full audit and cleanup. That is not a reason to doubt what its analyst saw. It does mean this is one vendor's account of its own casework, and that its prevention advice to use a firewall is also a product line. The cleanup order is useful whether or not you buy anything.

The eleven places

Sucuri's table numbers eight components, all of them files. A later section, "Where It Stores Persistence Off Disk", adds three places that are not. The table below keeps Sucuri's numbers for the first eight and continues from there. It is a map of where to look, not of what the code contains.

The eleven places. Rows 1 to 8 are Sucuri's table, rows 9 to 11 its off-disk section. Sucuri marks four file names as varying from site to site; the example names belong to one site.

No.	Place	What Sucuri says it does
1	.user.ini (also php.ini or .htaccess)	Sets auto_prepend_file so a loader runs before every PHP request in the directory tree. PHP caches the value.
2	Visible shim, such as wp-content/c1b12371.php (name varies)	Includes the hidden loader if it exists. If only the hidden file is removed, the shim does nothing and the site stays up.
3	Hidden loader, a dot-prefixed file beside the shim (name varies)	Rebuilds the mu-plugin from three sources: the plugin copy, an encoded stub in the cache directory and a ZIP restore bundle.
4	wp-content/db.php	Carries the whole payload as a gzip and base64 blob. Writes the plugin back when it is missing or too small.
5	wp-content/advanced-cache.php	Loads before ordinary plugins when caching is on. Rebuilds the plugin from five sources, two of them not files.
6	Active theme's functions.php	A fenced block at the bottom, the theme-resident twin of db.php. Rewrites the plugin when it goes missing.
7	Must-use plugin, hyper-engine-kit.php in the example (name varies)	The backdoor payload. Loads automatically and invisibly on every request.
8	Normal plugin copy of the same payload (name varies)	Identical to row 7, with a fake settings page. The payload keeps the two on the same version.
9	Database options row with a random name	The full payload in the same gzip and base64 form, read back by advanced-cache.php over its own database connection.
10	System V shared-memory segment, fixed numeric key	Readable PHP held in RAM. Survives file deletion and database cleanup. On shared hosting it can belong to another account.
11	Scheduled tasks	Cron hooks, some with random names, plus a known fetch hook. System cron runs the WordPress cron file, and redeployment follows.

Why eleven and not eight. Sucuri's overview says eight places "spread across files, the database, and shared memory". If that count included the database and the memory, there would be six files, but its table lists eight. We take the table as the better evidence and add the three off-disk stores. Eleven is a floor. The ZIP restore bundle, which has a random hex name and can sit in wp-content, in uploads or in a theme folder, and the encoded stub in the cache directory are files the table does not number. The control options and transients with an sc_ style prefix, the hidden administrator and, in related variants, database triggers are more artefacts again. Of the numbered eleven, 8 are files (73 per cent) and 3 are not (27 per cent). Both figures are derived.

How the three kinds of store rebuild each other

Sucuri's account is of a mesh, not a chain. Files rebuild files: db.php and the theme block each carry the whole payload, and the hidden loader rebuilds the must-use plugin from three file sources. Files also write the off-disk stores: the payload opens a raw database connection to insert its options row, bypassing WordPress, and writes the memory segment. And the off-disk stores rebuild the files: advanced-cache.php, which WordPress loads before ordinary plugins when caching is on, opens its own database connection with the site's credential constants and reads the options row, or reads the memory segment, then hooks the plugin back in. In Sucuri's words, "Delete the plugin and a drop-in rewrites it."

The arithmetic of that finder is the part to remember. Its five sources, in order, are the must-use plugin, a plugin copy, a shared-memory segment, a ZIP bundle and the database. Three are files and two are not, so 40 per cent of its sources survive any file-only cleanup. A cleaner who deletes both plugin copies and the ZIP bundle has not touched either of the other two (derived). Three further details bear on the order of work.

• The prepend runs first and runs everywhere. The .user.ini directive makes PHP run a loader "even on requests that never reach WordPress", so a security plugin that runs inside WordPress cannot see those requests. PHP caches the value, which is why Sucuri says to empty the target before deleting it. The PHP manual confirms the cache: user INI files are re-read every 300 seconds by default, and they are processed only under the CGI and FastCGI server APIs, while under Apache's module .htaccess does the same job.
• A stored copy is dangerous only while something can read it. Sucuri says of the memory segment that it "becomes harmless once the drop-ins that read it are gone". Its overview says that cleaning every file on disk still restores everything from the database or memory. Both hold only if "every file" means every file the cleaner found. Our reading: the reader you missed is the one that rebuilds everything, and finding it is a comparison job, not a search for names.
• Scheduled tasks are the vague one. Sucuri says the infection registers cron hooks and that system cron then runs the WordPress cron file. It does not say which copy a scheduled run redeploys from, or whether the malware also writes to the account's own crontab. We would check both.

Five labels that do the attacker's work

Each of these is a statement a client may hear after a cleanup. Each covers something narrower than it sounds.

• "The malware scan is clean." A scan reports on what it reads. SC keeps readable PHP in a memory segment, a payload in an options row, scheduled tasks and, in variants, database triggers. Whether any given scanner reads those is a question for its vendor, and Sucuri's post tests no product. There is a second problem. Sucuri says the payload can be told to deactivate and delete security plugins, so a missing scanner may be a symptom and not a configuration choice.
• "We reinstalled WordPress core." WordPress's own upgrade guide says to keep wp-config.php, the wp-content folder and .htaccess when replacing core. Seven of the eight rows in Sucuri's table sit under wp-content, and the eighth, .user.ini, is placed only in "that directory tree". A core reinstall done the documented way leaves them where they are. WP-CLI's checksum command verifies files against WordPress.org's checksums, and a drop-in, a must-use plugin or a commercial theme is not a WordPress.org file (our reading).
• "It is a caching plugin." In Sucuri's example the fake plugin carries a settings page, a shortcode and an activation hook. WordPress's documentation says must-use plugins do not show in the default plugin list and cannot be disabled from wp-admin, and Sucuri says the payload also removes itself from the plugin list, the update transient and the network views. At 19:17 BST on 1 October the WordPress.org API had no theme called khorshidi and no plugin called hyper-engine-kit, while a control lookup for a real theme answered normally. Sucuri says such names vary, so their absence is no indicator. It does mean WordPress.org holds no copy to check yours against.
• "There is no unknown administrator." Sucuri says the account is hidden from the user list, the user counts and the role views, and that the payload forges valid login cookies for it. Wordfence's possibly related sample also hides its account, and Wordfence says reading the database directly is the reliable way to see it. In related variants a database trigger recreates an administrator on insert, which in Sucuri's words makes "cleaning users pointless until the trigger is gone".
• "We restarted the server." A restart clears none of the stores. The Linux manual says a shared-memory segment is destroyed only after the last attached process detaches and must be removed explicitly, or its pages stay in memory or swap. The first request after a restart then runs whatever is still on disk.

A second report, nine days earlier, looks related. Neither says so

Wordfence published "Inside a Malicious, Stealthy WordPress Must Use Plugin" on 22 September, nine days before The Hacker News covered Sucuri's. Its author, per Wordfence's own feed, is Janet Katile. Wordfence's team found its sample in mid June during a site clean and released a detection signature on 23 June 2026. Wordfence's page answered our request with an empty 202 response, which we did not try to get around. We read the post's text from Wordfence's public RSS feed instead, and saw no figures.

Traits from the two vendor posts, side by side. A shared trait is not a shared author. Sucuri's post does not cite Wordfence's, and Wordfence's came first.

Trait	Sucuri SC, 30 September	Wordfence sample, 22 September
Obfuscation	A table of scrambled strings and a decoder using a positional substitution cipher. No readable function names.	A lookup table of encoded strings and a decoder using a substitution cipher.
Where it sits	db.php, advanced-cache.php, a theme's functions.php, mu-plugins and plugins.	Detections under "more than 4,000 distinct filenames", most often the same two drop-in names and a theme's functions.php.
Command channel	Roughly twenty public Ethereum gateways and contract method selectors.	Three contract addresses and 21 public gateways, picked at random each time.
Hidden administrator	Hidden from the user list, counts and role views. Forged login cookies.	Hidden from the user list, the REST API and the counts. Credentials kept in options.
Naming habit	"SC_" markers. Control options and transients with an sc_ style prefix.	Transients and an option with an sc_ prefix in its code excerpts.
Self-restore	Options row, shared memory, ZIP bundle, drop-ins and theme block.	A saved copy in a database option, written back if the file is missing or small. No shared memory in the post.
Extra in this one	A .user.ini prepend, and database triggers in related variants.	Plaintext capture of administrator passwords at login, theft of payment-gateway settings, and copying itself into other WordPress installs on the server about every three days.

What this does and does not establish. The overlaps are specific, and the sc_ prefix in particular looks like one author's habit. That is inference. Neither post cites the other, and neither says the two are one family. If they are, three things follow, all of them inference. SC would be at least 99 days old, counting from Wordfence's 23 June signature to Sucuri's 30 September post. Wordfence's count of more than 4,000 filenames would be the only scale figure in the record, and it counts filenames in Wordfence's detections, not sites. And the sibling's extra behaviours, password capture, payment-credential theft and spreading to neighbouring installations, would belong on your risk list. If they are not one family, you have two families sharing a toolkit. The defender's action is the same either way.

Wordfence's own indicator list for its sample names four option names (src, bu, bp and ic), administrator usernames made of one of four prefixes (admin_, adm_, administrator_ or backup_) and six random characters, and unfamiliar names among the custom cron schedules. Wordfence itself calls file hashes and plugin metadata unreliable, because they differ between samples. Short option names are weak evidence on their own, and Sucuri's post names none of them, so treat a match as a reason to look and not as proof of SC.

How it got in: nobody says

The Hacker News says it is "not known how the malware is delivered" and then lists the usual ways WordPress sites are broken into: flaws in WordPress, plugins and themes, weak logins, supply-chain attacks and insecure upload features. That list is the news site's own, not a finding from Sucuri. Sucuri's post names no entry point. Its prevention section says most compromises it handles exploit known, already-fixed flaws in outdated components, which is a statement about its caseload and not about SC. Wordfence's post does not say how its sample arrived either.

Cleanup and verification, in the order worth doing

Items marked Sucuri follow its report. Items marked Ours are our additions, and no source tests them. The order matters more than any single deletion: in Sucuri's words, removing files first, in the wrong order, "simply triggers a rewrite". The diagram ties the order to the eleven places.

What we could not verify

The question this leaves

Sucuri's closing advice is to treat the files, the database and shared memory "as one problem". A site that comes back from cleanup with a clean scan has answered only the question the scanner asked. So the question for your own process: when you tell a client a WordPress site is clean, which of the eleven places did you look at, and what record would have shown you were wrong? A list taken before the compromise of what should sit in wp-content, in the options table, in the scheduled tasks and among the administrator accounts would answer it. A list of bad file names would not, because Sucuri says the names vary from site to site.

Key facts