WordPress Backdoor Rebuilds Itself After Cleanup Using Files, Database, and Shared Memory
- ID
- 30834
- Status
- summarized
- Published
- 01 Oct 2026, 10:37 PM
- Fetched
- 02 Oct 2026, 12:26 AM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/10/wordpress-backdoor-rebuilds-itself.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 6.0
- Created
- 02 Oct 2026, 12:28 AM
- Tags
- Audience
- developerssaas_startup_founders
What happened
Sucuri researchers documented a WordPress compromise, codenamed SC after "SC_" markers in injected content, that maintains at least eight simultaneous persistence points across files, the database, and System V shared memory. Named components include .user.ini setting auto_prepend_file, loaders at wp-content/c1b12371.php and its dot-prefixed twin .c1b12371.php, db.php carrying a Base64-encoded compressed payload, advanced-cache.php rebuilding the plugin from five sources, and a theme copy at wp-content/themes/khorshidi/functions.php. Researcher Gabriel Barbosa describes it as a "self-healing mesh" in which each location can rebuild the others; the code uses no readable function names and is scrambled with a substitution cipher, and Sucuri says it is blockchain-controlled. The excerpt does not state affected WordPress versions, an entry vector, or a CVE.
Why it matters
If you run or host WordPress sites for clients — common for Malaysian agencies and SME brochure/e-commerce sites — your standard cleanup of deleting the malicious plugin or theme file is insufficient here: db.php, advanced-cache.php, .user.ini, and a shared-memory segment each restore the rest, so remediation has to cover database options, drop-ins, mu-plugins, and shared memory, or you reimage the host. Note the excerpt gives no affected versions, entry vector, or CVE, so you cannot yet say which sites are at risk from this text alone — treat any "cleaned" WP site as potentially reinfected until you check all eight locations.
Discussion angle
Does your incident-response checklist assume 'delete the file' equals 'cleaned'? Walk through which of the eight locations (db.php, advanced-cache.php, .user.ini, mu-plugins, System V shared memory) your cleanup process actually inspects — and whether shared hosting even lets you see the shared-memory segment.