From a 7 KB file to a 13-year backdoor operation

Security Research

From a 7 KB file to a 13-year backdoor operation

June 16, 2026 · Austin Ginder

Most plugin closures are uneventful. A developer stops responding, wp.org pulls the plugin, the listing goes dark, and that is the end of it. My WP Beacon scanner flags these all day long. I glance at them and move on.

One of them recently was different. The wp.org Plugin Review Team had not just closed a plugin called wp-advanced-math-captcha. They had reached into it and deleted a single 7 KB binary file. A .dat file. Routine closures typically do not touch random binaries. So I decoded it.

That one decision pulled a thread that did not stop unraveling. It led to a second plugin, then a brand I had never heard of, then one DNS lookup that tied everything together, and finally to a back catalog of 27 plugins going all the way back to 2013. Then, weeks later, when I stopped waiting for lucky signals and went looking on purpose, it led to six more burner plugins. Then nine more after that. What looked like a handful of unrelated anonymous developers turned out to be a single operator running the same infrastructure across nineteen accounts for thirteen years. Here is the whole thing, start to finish.

7 KB<br>File that started it

44<br>Plugins under their control

13 yrs<br>Operating in plain sight

19<br>wp.org accounts, one operator

It started with a file that should not have been there.

When the review team commits to a closed plugin, it is a signal. The account plugin-master only shows up when wp.org has triaged something as an actual incident, not just an unmaintained listing. So when the cleanup commit on wp-advanced-math-captcha specifically removed a file called wp-math-captcha.dat, that got my attention. Captcha plugins do not ship compressed binaries.

The file was zlib compressed. Decoding it took one line.

python3 -c "import zlib; print(zlib.decompress(open('wp-math-captcha.dat','rb').read()).decode())"

Out came PHP. A dropper. And right at the top of it, a comment block that told me exactly what I was looking at.

/**<br>* SiteGuarding tools installer for customer's panel<br>* https://www.siteguarding.com<br>* Do not distribute or share.<br>* ver.: 1.7<br>* Date: 20 Mar 2020<br>*/

The dropper carried a base64 copy of a backdoor named siteguarding_tools.php. On install it wrote that backdoor into the WordPress root, posted the site URL to apitest.siteguarding.com to register the new infection, and then deleted itself. A captcha plugin with six thousand active installs had been quietly planting a remote-access tool on every site that ran it.

What the .dat file actually was<br>Not data. A self-deleting installer. It dropped a 482-line backdoor into the site root, phoned home to register the infection, and erased the evidence of itself. The plugin looked like a math captcha. The .dat was the entire payload, hidden as a compressed binary so a casual reviewer would scroll right past it.

What else did they leave behind?

The review team had deleted the .dat file. They had not deleted everything. Sitting in the same plugin was includes/advert-test-codes.php, untouched, and it hardcoded a target:

define( 'ADVREC_TARGET_PLUGIN', 'image-optimizer-x' );

A captcha plugin had no business naming an image optimizer in its code. This was a forced-install primitive, a way to push a second plugin onto sites running the first. So I went and pulled image-optimizer-x from the SVN trunk to read it.

The sibling pointed at a brand I had never heard of.

image-optimizer-x was clean when it first launched in 2025. Then on December 16 it grew a 981-line file called CMSPlughubAPI_LicenseValidator.php. It claimed to validate licenses and update a GeoIP database. What it actually contained was two hardcoded RSA private keys and a generic file-downloader, all pointed at a domain called api.cmsplughub.com.

Embedding RSA private keys in a free WordPress plugin makes no sense for licensing. Private keys are for signing and decrypting, not checking a license. These were there for one reason: authenticated, two-way control of the host. But cmsplughub.com was a brand I had never seen, with no obvious connection to the captcha plugin or to SiteGuarding. On the surface these were two unrelated indie plugins from two different developers.

One DNS lookup closed the case.

Before reading 981 lines of obfuscated validator code, I did the cheap check first. I looked up where cmsplughub.com lived.

Claude Code Session<br>Austin<br>cmsplughub.com keeps showing up in this image plugin. Run whois and check the nameservers. Is it connected to siteguarding at all, or am I chasing a coincidence?

Claude<br>Not a coincidence. Same operator. dig NS cmsplughub.com returns ns1.siteguarding.com and ns2.siteguarding.com. Both cmsplughub.com and siteguarding.com resolve to 198.7.59.167, and the reverse DNS on that IP is server2.siteguarding.com. cmsplughub.com was registered 2025-02-11 as a fresh brand, but it is sitting on...