A routine WordPress plugin closure turned into a multi-month investigation after a security researcher noticed something unusual in the repository cleanup: the WordPress.org Plugin Review Team had deleted a single binary file from a closed captcha plugin rather than simply pulling the listing. That detail was enough to unravel a coordinated malware campaign spanning 42 plugins, 19 anonymous accounts, and 13 years of activity on WordPress.org.
The file in question was wp-math-captcha.dat, a zlib-compressed blob sitting inside wp-advanced-math-captcha, a plugin with roughly 6,000 active installs. Decompressing it revealed a PHP dropper branded with the name SiteGuarding — a website security company — complete with a comment block dated March 2020. The dropper wrote a remote-access backdoor called siteguarding_tools.php into the WordPress root directory, then silently reported the site’s URL to apitest.siteguarding.com to register the new infection before deleting itself.
The captcha plugin was not working alone. Its source code contained a hardcoded reference to a separate plugin, image-optimizer-x, as a forced-install target — a mechanism to push a second plugin onto sites already running the first. That second plugin, on December 16 2024, had grown a 981-line file embedding two RSA private keys and a file downloader pointed at api.cmsplughub.com. According to the researcher, a DNS lookup on that domain found it hosted on SiteGuarding’s own nameservers and IP address, on a server named server2.siteguarding.com. The researcher attributes all three accounts — @siteguarding, @lulub5592, and @dalielsam — to the same operator.
- The captcha plugin’s dropper planted the identical backdoor, same MD5 hash, found across 15 plugins in the original 2013–2020 @siteguarding portfolio
- The captcha plugin hardcoded the image optimizer as a forced-install target, linking the two anonymous accounts
- The image optimizer’s backend domain ran on SiteGuarding’s own infrastructure, closing the attribution loop
- Both burner accounts were closed by WordPress.org on the same day — April 7, 2026 — after a coordinated rollout 30 days apart the previous winter
The original @siteguarding account had published 27 plugins between 2013 and 2020, every one of which was closed by WordPress.org in a single sweep between May 4 and June 5, 2020. Analysis of those plugins found that 15 shipped the siteguarding_tools.php backdoor inline — including plugins marketed as security tools such as wp-admin-protection, wp-badbot-protection, and toxic-links-scanner. The remaining 12 phoned home to siteguarding.com on their own schedule without an inline payload, including the portfolio’s largest plugin, wp-antivirus-site-protection, which had over 4,000 active installs and had been calling home since 2014.
The researcher’s systematic sweeps of the closed-plugin corpus uncovered six additional burner plugins beyond the initial two. Three surfaced because WordPress.org had force-pushed remediation commits at the time of closure — a step the team typically takes after confirming malware. One of those, wp-plugin-management, included an admin notice that named all three command-and-control domains verbatim and described the attack in plain language to affected site owners. Three more emerged from a second sweep that decoded every non-PHP data file in the closed-plugin archive, catching payloads disguised under .dat, .gzs, and .bin extensions.
The later-generation plugins introduced a persistence technique absent from the 2013 portfolio: patching wp-config.php directly with an include_once statement so the payload loads before WordPress boots, surviving both plugin deactivation and deletion. One plugin, cls-lcp-issues-fix, also downloaded a fresh payload encoded with ionCube — a commercial PHP obfuscator — from SiteGuarding’s servers on each run, allowing the operator to swap the live malware server-side at any time without touching the plugin itself.
In total the investigation attributed 42 plugins across 19 WordPress.org accounts to a single operator running consistent infrastructure from 2013 through at least early 2026. Sites that installed any of these plugins between those dates — particularly anything branded as a security, antivirus, or optimization tool from the accounts named — should audit their WordPress root directories and wp-config.php for the presence of siteguarding_tools.php or unexpected include_once injections.
