Sucuri documents SC, WordPress malware that rebuilds itself after every deletion
On September 30, 2026 Gabriel Barbosa of Sucuri described a WordPress malware family the company calls SC. Its backdoor sits in at least eight places simultaneously, each piece able to restore the rest, it adopts or creates a concealed administrator account, and it takes orders from an Ethereum smart contract.
A backdoor that came back during cleanup
Gabriel Barbosa, a security analyst at the website security company Sucuri, published a detailed write-up on the company blog on September 30, 2026. His team ran into the infection while cleaning a compromised site: however carefully the team deleted the files it could see, the same backdoor reappeared seconds after each deletion. Sucuri named the family SC, after the "SC_" markers it found inside the injected code.
The central point of the analysis is that the payload behaves like a network rather than a single file. According to Sucuri, copies are kept in at least eight locations at the same time, and any one of them can recreate the others. Barbosa puts it bluntly: "Delete the plugin and a drop-in rewrites it." On October 1, 2026 The Hacker News, in a piece by Ravie Lakshmanan, relayed Sucuri's findings and listed the same eight file locations.
Eight file locations, three copies off disk
Sucuri's list covers an auto_prepend_file line in .user.ini, a visible loader in wp-content (c1b12371.php) and its hidden dot-prefixed twin, the wp-content/db.php and wp-content/advanced-cache.php drop-ins, a block appended to the active theme's functions.php, a fake must-use plugin at mu-plugins/hyper-engine-kit.php and an identical regular plugin under the same name in the plugins folder. Sucuri notes that file names change from site to site. Beyond these, one copy of the payload lives in the database options table and another in a System V shared-memory segment, while WordPress cron hooks schedule redeployment. Even if every file on disk is cleaned, the next page load brings the set back from the database or from shared memory.
The backdoor itself has several jobs. It filters itself out of the plugin list and plugin screens, including network views, and out of the update data WordPress keeps. It takes over an existing hidden administrator or creates a new one, inserting the account into the users and usermeta database tables itself if the standard WordPress API cannot be used, then keeps that account out of the user list, the user counts and the role views. Instead of a single command server, it ships with roughly twenty public Ethereum RPC gateways and reads its instructions from a smart contract. The reply can include front-end JavaScript to inject, which Sucuri says enables checkout skimming on a store, as well as new PHP code for installation and the names of security plugins it should deactivate and remove.
Deleting the visible file is not the same as cleaning the site
The case shows that removing the obvious files from a WordPress site does not end an infection, because copies can survive in the database and in server memory. In his conclusion Barbosa writes that "a modern WordPress infection can be a system rather than a file." Sucuri says that on a store the injected code enables checkout skimming, so for sites that take payments the exposure can reach customers' card details. That makes the order of the cleanup, a check for hidden administrators and the monitoring afterwards more decisive than any one-off file deletion.
Sucuri sets out a clear sequence. First the prepend directive is neutralised, and only then is its target removed. Next come the copies in the database, shared memory and transients, followed by scheduled tasks and database triggers, and then the hidden administrator. Files are cleaned in a single pass, and the site is scanned again and watched for anything that reappears. On prevention, Sucuri recommends keeping components patched and putting a web application firewall in front of the site. We covered why core updates should not wait in our article on the WordPress 7.1.1 security release; that piece is not directly related to this malware.
The sources say nothing about Türkiye, so this section is commentary
Neither source contains any information about Türkiye. There is no affected Turkish site, no local hosting company and no figure specific to the country. What follows is therefore not drawn from the sources but is explicitly UNALSOFT commentary.
Our reading: the technique SC illustrates, keeping copies in the database and in memory as well as in files, is a lesson for any business site or online store running WordPress, wherever it is based. Sucuri's note that on shared hosting the memory segment may belong to a different account matters for businesses on shared plans. The unknowns, one by one: the number of affected sites, the initial infection route in this case, whether the malware is tied to a named threat actor, whether card data was actually stolen on any checkout page, and whether any sites in Türkiye are affected are not covered by the sources.
The UNALSOFT view
We read this less as an alarm and more as a reminder about maintenance discipline. When a site is declared "clean", the useful question is not which file was deleted but whether the database option rows, scheduled tasks and administrator accounts were checked too. On sites that take payments, watching for JavaScript added to the front end later should be its own step. That is why in our web design projects we treat updates, backups and account audits as work that continues after handover. Because the sources carry no data about Türkiye, this article makes no estimate of local impact.
Is your site's cleanup really finished?
A short conversation is enough to review the update, backup and administrator account routine of your WordPress site together.