NEWS

WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database and Shared Memory

Sucuri found the SC WordPress backdoor rebuilding itself from eight file, database, and shared-memory locations, using Ethereum RPC gateways for C2.

Dylan H.

News Desk

October 4, 2026
7 min read
WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database and Shared Memory

SC Backdoor Turns a Single WordPress Infection Into an Eight-Way Self-Healing Mesh

Researchers at Sucuri have detailed a WordPress backdoor, codenamed SC after the SC_ markers it leaves inside injected code, that defeats conventional cleanup by storing identical copies of its payload across at least eight redundant locations spanning the filesystem, the WordPress database, and System V shared memory. Sucuri researcher Gabriel Barbosa described the design bluntly: "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." Rather than relying on a traditional command-and-control server, SC communicates with its operators through roughly 20 public Ethereum RPC gateways — a technique Sucuri calls a "self-healing mesh." The campaign has been tied to active exploitation of CVE-2026-1581, an unauthenticated SQL injection flaw (CVSS 7.5) in the wpForo Forum plugin, with attacks observed since July 3, 2026.


Details

AttributeValue
Backdoor nameSC (named for SC_ markers found in injected code)
Affected platformWordPress, including shared-hosting environments
Entry vectorSQL injection in vulnerable plugins (e.g., wpForo Forum)
Related vulnerabilityCVE-2026-1581 — wpForo Forum unauthenticated SQLi, CVSS 7.5, versions ≤ 2.4.14
Exploitation observed sinceJuly 3, 2026
Persistence mechanismsFilesystem drop-ins/loaders, theme file, duplicated fake plugin, database options row, System V shared memory segment, ZIP restore bundles, cron hooks
Command and control~20 public Ethereum RPC gateways (blockchain-based)
Discovered/reported bySucuri (researcher Gabriel Barbosa)
Report dateOctober 1, 2026

Eight Places at Once: The Filesystem and Theme Layer

According to Sucuri's writeup, SC seeds a .user.ini file that sets the auto_prepend_file directive so PHP silently executes a hidden loader before every request in the directory tree. Two matching loaders — one visible, one dot-prefixed, both given a random hex filename — sit in wp-content, each able to restore the other if one is deleted. Two further drop-ins, db.php and advanced-cache.php, are loaded by WordPress very early in its bootstrap sequence, before most plugins or security scanners run, and each carries a compressed, Base64-encoded copy of the backdoor that redeploys if the file is missing or undersized. A block appended to the active theme's functions.php mirrors the same logic, and a fake plugin — observed under the name hyper-engine-kit — is installed twice: once as a must-use plugin (which loads automatically and is often skipped by plugin-list scanners) and once as a standard plugin.

Database and Shared Memory: The Pieces File Scanners Miss

Beyond the filesystem, SC stashes a copy of its payload inside a WordPress database options row, and — on servers that support it — inside a System V shared memory segment identified by a fixed numeric key. Because that segment lives in RAM rather than on disk, it survives both file deletion and database cleanup, and Sucuri notes it can even be readable across tenants on shared hosting where memory isolation between accounts is weak. Randomly named ZIP restore bundles provide yet another fallback copy, and scheduled cron hooks periodically check whether any of the eight locations is missing and trigger a full redeploy. Sucuri summarized the effect: "Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it." A single surviving copy, anywhere in the chain, is enough to resurrect the entire infection on the next page load.

Blockchain-Based Command and Control

Instead of a conventional C2 domain or IP address that defenders could block or sinkhole, SC reaches its operators through a rotating pool of roughly 20 public Ethereum RPC gateways — legitimate infrastructure normally used by wallets and dApps to talk to the Ethereum network. If one gateway is blocked or goes offline, the malware simply moves to another, making network-layer blocking far less effective than it would be against a fixed C2 server.

Impact Assessment

Impact AreaDescription
Site integrityHidden administrator accounts, admin-panel entries concealed from the plugins screen, and bypassed update checks give attackers durable, low-visibility control
Visitor safetySC can fetch and inject arbitrary JavaScript, enabling skimming and other client-side attacks against site visitors
Remediation difficultyStandard "find and delete the bad file" cleanup fails outright — any single surviving copy across the eight locations triggers full reinfection
Detection evasionDatabase rows and RAM-resident shared memory segments are invisible to file-based malware scanners
Infrastructure resilienceBlockchain-based C2 over ~20 Ethereum RPC gateways resists conventional domain and IP blocklisting
Entry point exposureUnpatched plugin SQL injection (CVE-2026-1581) provides the initial foothold that seeds every later persistence layer

Recommendations

For WordPress Site Owners

  • Update the wpForo Forum plugin beyond version 2.4.14 immediately, and audit all other installed plugins for outstanding unauthenticated SQL injection advisories.
  • Rotate all credentials following any suspected compromise — WordPress admin passwords, database credentials, SFTP/hosting logins, and API keys — since a persistence mechanism this deep implies full site-level access was obtained.
  • Inspect the wp_options table for anomalous serialized blobs, review scheduled tasks under WP-Cron for unfamiliar hooks, and check the Users screen for admin accounts you did not create.
  • Check the mu-plugins directory specifically — must-use plugins load automatically and are frequently skipped by security scanners and even by site administrators reviewing the plugins list.
  • Prefer restoring from a known-clean backup taken before the compromise over file-by-file removal, which this backdoor is explicitly engineered to defeat.

For Hosting Providers and Agencies

  • Enumerate System V shared memory segments (ipcs -m) tied to customer PHP processes, particularly on shared hosting where cross-tenant memory exposure between accounts is possible.
  • Deploy WAF rules targeting known SQL injection patterns against wpForo and similarly vulnerable forum/community plugins, and consider flagging outbound connections from web processes to Ethereum RPC endpoints as a suspicious indicator.
  • Audit .user.ini and auto_prepend_file usage across hosted accounts for unauthorized or unexplained entries.

For Incident Responders

  • Treat SC as a system-level compromise, not a file infection — remediate the filesystem loaders, theme file, duplicated fake plugin, database options row, shared memory segment, ZIP bundles, and cron hooks simultaneously, in a single maintenance window.
  • Use ipcs -m and ipcrm to enumerate and clear shared memory segments as a standard step in WordPress IR runbooks going forward.
  • Capture a full database dump and diff wp_options and wp_usermeta before and after cleanup to confirm no persistence row survived.
  • Monitor outbound traffic for connections to public Ethereum RPC gateways post-remediation as a sign of incomplete cleanup.

Key Takeaways

  1. The SC backdoor stores identical payload copies across at least eight redundant locations spanning files, the database, and shared memory.
  2. File-only remediation fails by design — any single surviving copy anywhere in the chain triggers automatic full reinfection.
  3. System V shared memory persistence is a notable evasion technique: it lives in RAM, survives file and database cleanup, and is invisible to conventional scanners.
  4. SC's blockchain-based C2, routed through roughly 20 Ethereum RPC gateways, resists traditional domain and IP blocklisting.
  5. Initial compromise has been linked to CVE-2026-1581, an unauthenticated SQL injection flaw in the wpForo Forum plugin, exploited since July 3, 2026.
  6. Effective incident response requires a full-stack approach — filesystem, database, cron, and memory inspection plus credential rotation — not just deleting suspicious files.

Sources