WP Beacon
Campaign SiteGuarding 2013–present 10 audits
See also: #25 wp-advanced-math-captcha · #26 image-optimizer-x · #28 wp-antivirus-site-protection · #42 speedup-optimization · #44 bytedefense · #45 cls-lcp-issues-fix · #46 code-quality-control-tool · #47 magex-ai-bot-defender · #48 seo-pack

← All audits

Audit #43 Malicious Closed by wp.org

WP Install From Web Closed on WP.org · 100 installs · baseline — → head 1.10.1 · suspect committer safetydev · by beacon-scan-skill · closed 1d ago

Actor: SiteGuarding (SafetyBis Ltd.)
Show full summary

This is a previously-undocumented SiteGuarding supply-chain backdoor burner. It was surfaced by hunting for plugins that WP.org cleaned on closure — i.e. where a Plugin Review Team account force-pushed a code change at the moment of closure. For wp-plugin-management, WP.org's response was the most explicit possible confirmation.

The backdoor. The plugin ships plugin.dat, a zlib-compressed PHP file. The activation hook plg_EYS7S_activation() (registered via register_activation_hook) reads plugin.dat, gzuncompress()-es it into plugin.dat.tmp, and include()s it. The decompressed payload contains $siteguarding_tool_code — a base64 blob that decodes to siteguarding_tools.php v1.7 (dated 20 Mar 2020), the SiteGuarding RCE backdoor documented in audits #25/#26: IP allowlist 185.72.157.169-172, SITEGUARDING_SERVER = http://www.siteguarding.com/ext/panel_api/index.php, and an embedded RSA private key (the same key bundled in the v2.1 sample from audit #26). Installing the plugin plants a web-accessible RCE backdoor in WordPress root.

WP.org's cleaning commit is a written confession. Rather than only closing the plugin, frantorres force-pushed v1.10.1.1 — a remediation release whose activation hook now deletes siteguarding_tools.php and webanalyze/siteguarding_tools.php, and whose admin notice states verbatim: "this plugin included an obfuscated file, plugin.dat, which was then uncompressed into a file named plugin.dat.tmp. This file was executed, sending your website's URL to apitest.siteguarding.com and installing a 'Remote Management Tool' in the root directory as a file named siteguarding_tools.php. This tool allows connections from specific IPs belonging to siteguarding.com and safetybis.com servers ... It enabled remote control of your website, allowing third parties to access, modify, and execute code on your site."

Why the IOC scanner missed it. The backdoor lives inside plugin.dat (gzip+base64), not in a .php file, so the existing high-confidence IOCs (siteguarding_tool_code, SITEGUARDING_SERVER, the IP literals) never matched a PHP grep. Detection came from the clean-on-closure signal, not code-pattern matching.

Exposure. ~100 active installs at closure. Closed plugins stop distributing, but the v1.7 siteguarding_tools.php (and its webanalyze/ backup copy) may persist in WordPress root on sites that never updated to the remediation release.

🛑
100 installs potentially exposed to compromised code.

Site owners should remediate immediately. Plugin author: see the steps below to clear this label.

If you run wp-plugin-management on your site

Verify your install matches the wp.org canonical version:

wp plugin verify-checksums wp-plugin-management

A patched build isn't yet published for this audit. Check the security advisories index or remove the plugin until one is available.

Or remove the plugin entirely:

wp plugin deactivate wp-plugin-management
wp plugin delete wp-plugin-management

If you're the plugin author

Cleanup steps to clear this label have not yet been documented for this audit. Contact the investigator listed above.

The label clears automatically on the next wp beacon scan-deltas once the cleanup conditions above are met.

Plugins under the same committer's SVN access

safetydev holds push access to 1 plugin totalling 100 active installs.

WP Install From Web — COMPROMISED — this audit
100

IOCs extracted (3)

Kind Value Confidence
code_pattern $siteguarding_tool_code high
code_pattern plg_EYS7S_activation high
filename plugin.dat.tmp medium

Audit #43 — wp-plugin-management

  • Plugin: wp-plugin-management ("WP Install From Web")
  • Active installs: 300+ (at closure — recovered via Wayback 2026-03-16 snapshot; live record had decayed to 100)
  • Event: #3164 recent_prt_intervention · medium · clean-on-closure hunt 2026-06-14
  • Suspect committer / account: safetydev (joined 2020-07-02 — one day after burner @lulub5592, 26 days after the SiteGuarding 2020-06-05 mass ban)
  • Pre-clean trunk: r3302992 (safetydev, 2025-05-29)
  • WP.org cleaning commit: r3507884 (frantorres, 2026-04-16 "New version 1.10.1.1")
  • Closed on wordpress.org: 2026-04-16 (empty closed_reason)

Summary

This is a previously-undocumented SiteGuarding supply-chain backdoor burner. It was surfaced by hunting for plugins that WP.org cleaned on closure — i.e. where a Plugin Review Team account force-pushed a code change at the moment of closure. For wp-plugin-management, WP.org's response was the most explicit possible confirmation.

The backdoor. The plugin ships plugin.dat, a zlib-compressed PHP file. The activation hook plg_EYS7S_activation() (registered via register_activation_hook) reads plugin.dat, gzuncompress()-es it into plugin.dat.tmp, and include()s it. The decompressed payload contains $siteguarding_tool_code — a base64 blob that decodes to siteguarding_tools.php v1.7 (dated 20 Mar 2020), the SiteGuarding RCE backdoor documented in audits #25/#26: IP allowlist 185.72.157.169-172, SITEGUARDING_SERVER = http://www.siteguarding.com/ext/panel_api/index.php, and an embedded RSA private key (the same key bundled in the v2.1 sample from audit #26). Installing the plugin plants a web-accessible RCE backdoor in WordPress root.

WP.org's cleaning commit is a written confession. Rather than only closing the plugin, frantorres force-pushed v1.10.1.1 — a remediation release whose activation hook now deletes siteguarding_tools.php and webanalyze/siteguarding_tools.php, and whose admin notice states verbatim: "this plugin included an obfuscated file, plugin.dat, which was then uncompressed into a file named plugin.dat.tmp. This file was executed, sending your website's URL to apitest.siteguarding.com and installing a 'Remote Management Tool' in the root directory as a file named siteguarding_tools.php. This tool allows connections from specific IPs belonging to siteguarding.com and safetybis.com servers ... It enabled remote control of your website, allowing third parties to access, modify, and execute code on your site."

Why the IOC scanner missed it. The backdoor lives inside plugin.dat (gzip+base64), not in a .php file, so the existing high-confidence IOCs (siteguarding_tool_code, SITEGUARDING_SERVER, the IP literals) never matched a PHP grep. Detection came from the clean-on-closure signal, not code-pattern matching.

Exposure. ~100 active installs at closure. Closed plugins stop distributing, but the v1.7 siteguarding_tools.php (and its webanalyze/ backup copy) may persist in WordPress root on sites that never updated to the remediation release.

Verdict

malicious

Attribution

SiteGuarding (siteguarding.com / dissolved SafetyBis Ltd.). Burner fleet now >=5 plugins / 5 accounts: @lulub5592 (wp-advanced-math-captcha, #25), @dalielsam (image-optimizer-x, #26), and the three found in this hunt: @safetydev (this plugin), @charlycharm (speedup-optimization, #42), @lanechristian891 (bytedefense, #44). @safetydev registered 2020-07-02, one day after @lulub5592.

IOCs to extract

  • kind: code_pattern, value: plg_EYS7S_activation, confidence: high
  • kind: code_pattern, value: $siteguarding_tool_code, confidence: high
  • kind: filename, value: plugin.dat.tmp, confidence: medium

Cleanup

Sites that ran this plugin: delete siteguarding_tools.php from WordPress root and webanalyze/siteguarding_tools.php; remove the webanalyze/ directory; block outbound to siteguarding.com, apitest.siteguarding.com, safetybis.com, and 185.72.157.0/24. Follow the full SiteGuarding cleanup checklist (audit #25/#27 writeup).

Everything in this audit is reproducible from the links cited above: SVN log, RDAP records, GitHub repositories, wp.org forum threads, and any live endpoints. Full WP Beacon scan logs and any associated zip artifacts are available on request from the investigator.