Threat intel

SC: the WordPress backdoor that rebuilds itself

By Yaali. October 9, 2026, 6 min read, Threat intel, Resilience, Vulnerabilities.

Sucuri found a WordPress backdoor that hides in eight files, the database and shared memory. How it regrows, the cleanup order that works, and what to check.

Sucuri researcher Gabriel Barbosa published an analysis on September 30 of a WordPress backdoor the company calls SC, after the SC_ markers it leaves in injected code. Sucuri found it during incident response work in September. The payload sits in at least eight places at once across files, the database and shared memory, and each copy can rebuild all the others. Delete the fake plugin and a drop-in writes it back on the next page load; clean the files and the database or a RAM segment restores the full set.

If you run WordPress and have ever "cleaned" a site only to find it reinfected days later, this is the pattern to check for. Sucuri did not identify how the sites it handled were first broken into, and notes that most compromises it sees go through known, already fixed flaws in outdated plugins and themes. Once SC is in, it hides an administrator account, steals admin session tokens, can push card skimming JavaScript to store checkouts, and takes its orders from an Ethereum smart contract rather than a server that could be seized.

How it works

PHP and WordPress both offer several ways to run code before a page is built, and SC uses nearly all of them. A .user.ini file sets auto_prepend_file, a PHP setting that runs a chosen file before every script on the account. That points at a small shim (wp-content/c1b12371.php in Sucuri's sample), which loads a hidden, dot-prefixed loader (wp-content/.c1b12371.php). Sucuri says the file names change from site to site.

Two WordPress drop-ins follow. Drop-ins are files in wp-content that WordPress loads early by name, before ordinary plugins: db.php normally replaces the database layer, and advanced-cache.php normally belongs to a caching plugin. SC's db.php carries the whole backdoor as a gzip and Base64 blob and rewrites the plugin if it is missing or too small. Its advanced-cache.php can rebuild the plugin from five sources: the must-use plugin, the regular plugin copy, the shared-memory segment, a ZIP restore bundle with a random hex name, and the database.

The payload itself sits in two places: wp-content/mu-plugins/hyper-engine-kit.php (must-use plugins load automatically and cannot be switched off from the dashboard) and a duplicate at wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php. A marked block at the end of the active theme's functions.php carries the same payload as db.php.

Off disk, SC keeps a gzip and Base64 copy in a randomly named row of the wp_options table and, on servers with System V shared memory, a readable PHP copy in a RAM segment under a fixed numeric key. Neither survives in a file listing, so a file scan comes back clean while the site is still infected. Cron hooks with random names and, in related variants, MySQL triggers that recreate an administrator on insert, finish the set.

Instructions come from a smart contract read through a list of about 20 public Ethereum RPC gateways (the web services wallets use to query the chain), so there is no single command server to block or take down.

What attackers are doing with it

Once running, the payload hides itself from the plugin list, the update check and the network admin views, and injects admin-side JavaScript to scrub its row from the plugin table. It creates or takes over an administrator account, writes it straight into the wp_users and wp_usermeta tables, hides it from user lists and counts, and can forge that account's login cookies.

It collects the site URL, host, WordPress and plugin versions, active themes, the mu-plugin list and administrator session tokens, encrypts them and sends them out. Replies from the contract can carry front-end JavaScript (Sucuri names checkout skimming on stores), new PHP to install, and lists of security plugins to deactivate and delete. It also opens raw database connections with the credentials in wp-config.php, bypassing WordPress entirely.

Some coverage of the research tied SC to CVE-2026-1581, a time-based SQL injection in the wpForo Forum plugin through the wpfob parameter. Reports quoting Sucuri describe that flaw as unrelated to the SC campaign. It still deserves a patch: it affects wpForo 2.4.14 and earlier, needs no login, and is fixed in 2.4.15. NVD scores it 7.5 and Patchstack 9.3; Patchstack lists it as known to be exploited.

What to do

Order matters. Sucuri's sequence, and why each step comes where it does:

1. Neutralise the prepend first. PHP caches auto_prepend_file for up to 300 seconds. Replace the target file's contents with an empty <?php stub, then remove the directive from .user.ini, php.ini and .htaccess. Deleting the target while the cache is warm can break every PHP request on the account.
2. Clear the off-disk copies next. Delete the payload row in wp_options, the sc_-prefixed control options and transients, and the shared-memory segment. On Linux, ipcs -m lists segments and ipcrm -m <id> removes one. On shared hosting the segment may belong to another account, so ask the host to remove it.
3. Clear the malicious cron hooks and run SELECT TRIGGER_NAME, EVENT_OBJECT_TABLE, ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = DATABASE(); to find triggers that recreate admins.
4. Delete the hidden administrator and the orphaned option that stores its user ID.
5. Clean every file in one pass: the shim and hidden loader, both plugin copies, the ZIP bundle, and the injected db.php and advanced-cache.php. In functions.php, trim only the marked block.
6. Rescan. A file that comes back means a persistence point survived or the way in is still open.

To check whether you are hit, look for:

• auto_prepend_file in .user.ini, php.ini or .htaccess pointing at a hidden dot file. grep -rn auto_prepend_file --include=.user.ini --include=.htaccess --include=php.ini /path/to/site finds them.
• db.php or advanced-cache.php in wp-content with an SC_ begin marker, or present when you run no plugin that needs them.
• The same plugin file in both mu-plugins and plugins.
• A random hex ZIP in wp-content, wp-content/uploads or a theme folder.
• A large Base64 value in wp_options, or option names starting with sc_.
• A shared-memory segment whose contents start with <?php.
• An administrator in wp_users (query the table directly, since the dashboard hides it) that you did not create.
• Outbound HTTPS from the web server to public Ethereum RPC gateways. Sucuri advises blocking the whole set rather than the one you saw.

Afterwards, assume the attacker read everything the site could reach. Rotate the database password and wp-config.php salts, which invalidates forged cookies, reset every administrator password, and update every plugin and theme so the original way in is closed. If the site takes payments, review checkout pages for injected script.

Beyond this one backdoor

SC works because most cleanups stop at the file system. A cleanup checklist that covers wp_options, information_schema.TRIGGERS, cron hooks, drop-ins and server-level PHP settings covers every place SC hides. File integrity monitoring on wp-content plus alerts on new administrator rows would have flagged SC the first time it rebuilt itself.

We hunt for this kind of persistence in web penetration testing and in security operations monitoring. If a WordPress site keeps getting reinfected, open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Sucuri, The Hacker News, Daily Security Review, Wordfence (CVE-2026-1581), Patchstack (CVE-2026-1581), NVD.