"The payload lives in at least eight places at once, spread across files, the database, and shared memory, and every one of those places can rebuild all the others," security researcher Gabriel Barbosa said.
The eight-file, database, and memory architecture
Researchers at Sucuri dissected a WordPress compromise that assembles the same backdoor payload in multiple locations so any surviving copy can restore the whole infection. The campaign's backdoor — codenamed "SC" for the "SC_" markers in injected content — places components in at least eight distinct locations: a per-directory PHP loader directive (.user.ini), two loader files in wp-content (a visible loader and a dot-prefixed first stage), a db.php bootstrap payload, an advanced-cache.php cache loader, a theme functions.php copy, a must-use (mu-) plugin, and a regular plugin duplicate.
- .user.ini — sets auto_prepend_file to run a loader before every PHP request in that directory tree.
- wp-content/c1b12371.php — a loader that includes a hidden dot-prefixed file when present.
- wp-content/.c1b12371.php — the first-stage hidden loader that locates and rebuilds a fake plugin in mu-plugins from three sources (existing plugin copy, an encoded cache stub, and a ZIP restore bundle).
- wp-content/db.php — loaded during bootstrap and carrying the entire backdoor compressed and Base64-encoded; it decodes and redeploys the plugin when missing or too small.
- wp-content/advanced-cache.php — executed before ordinary plugins when caching is enabled; it rebuilds the plugin from five independent sources and hooks plugins_loaded.
- wp-content/themes/khorshidi/functions.php — a theme-resident twin of db.php that rewrites the plugin when absent.
- wp-content/mu-plugins/hyper-engine-kit.php — the must-use plugin carrying the malware.
- wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php — a duplicate installed as a normal plugin for redundancy.
Persistence techniques: shared memory and scheduled redeployment
Sucuri's analysis highlights two persistence primitives that complicate cleanup. Where System V shared memory is supported, the payload is written into a memory segment identified by a fixed numeric key. Because that segment lives in RAM it survives file deletion and database cleanup, and on shared hosting it "can even be owned by a different account." The infection also registers cron hooks — including randomized names alongside a known fetch hook — and relies on system cron running WordPress's cron file to trigger redeployment on schedule, not only visitor traffic.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildDeceptive coding and blockchain command-and-control
SC deliberately obscures its internals. Sucuri reports the malware uses a decoder and a substitution cipher so there are no readable function names. Its operator communication channel is hidden inside legitimate blockchain infrastructure: the backdoor communicates with a command-and-control (C2) server using the Ethereum blockchain. Once in contact, the payload fingerprints the infected site, retrieves additional payloads, and can fetch arbitrary JavaScript for injection into visitor pages — enabling skimmer deployments or other client-side attacks.
Capabilities observed on infected sites
Across methods used to launch or maintain the backdoor, Sucuri observed a consistent set of actions: the malware hides itself from the admin plugins screen and update checks; creates a hidden administrator account; executes arbitrary PHP; and can deactivate or delete specific plugins. The must-use and duplicate plugin deployment pattern, plus database- and cache-based storage, produces a circular system that restores itself "from any surviving copy on the very next request," Sucuri said — a behavior the company described as a "self-healing mesh" that's "blockchain-controlled."
wpForo SQL injection (CVE-2026-1581) and exploitation telemetry
The disclosure of SC comes alongside active exploitation of a high-severity, unauthenticated SQL injection in the wpForo Forum WordPress plugin: CVE-2026-1581 (CVSS 7.5). The vulnerability affects all versions up to and including 2.4.14. Telemetry from Previdian recorded fewer than 20 exploitation attempts targeting the flaw since July 3, 2026, originating from five unique IP addresses located in Bulgaria, Switzerland, France, the U.S., and Yemen.
What this means for site operators, security teams, and developers
- Site operators and hosting administrators should expect that removing files alone may not be sufficient: Sucuri's findings show recovery requires inspection of database entries, cache and drop-in files, theme code, mu-plugins, and System V shared-memory segments where available.
- Security teams should treat SC's channeling through Ethereum as an indicator that network and blockchain-related IOCs will be needed in addition to file-based signatures, and should monitor cron activity and unexpected mu-plugin or advanced-cache.php changes.
- Plugin and theme developers — and procurement teams that deploy them — need to note that known vulnerabilities such as CVE-2026-1581 in wpForo can be actively exploited; telemetry in this case showed a small but geographically diverse set of attempts since July 3, 2026.
SC reframes a common assumption: modern WordPress infections can be a distributed system rather than a single malicious file. As Sucuri puts it, the toolkit "spreads identical copies of one backdoor across drop-ins, the theme, a fake plugin in two locations, the database, and shared memory" and "rewrites itself from any surviving copy on the very next request." The practical consequence is clear — cleanup and hardening must be as systemic as the infection itself.
