Find ClickFix and EtherHiding scripts, web shells and new admins on WordPress, then strip known injected scripts from pages. Runs on your own site.
Security Guard scans your WordPress site for injected-script malware, web shells, new administrators and changed core files, takes known injected scripts out of your pages, and limits where page scripts may connect with a Content-Security-Policy. It runs on your own server, sends no site files anywhere, and never deletes or edits a file it flags.
A read-only scan checks your plugin, theme and must-use code, the uploads folder (including PHP hidden in images), the database, administrator accounts and WordPress core files. It looks for blockchain loader (EtherHiding) and fake verification (ClickFix) patterns, web shells and obfuscated loaders. Results stay in a private, randomly named folder on your server, and once you clean something up it no longer comes back on the next scan.
Remove injected scripts takes inline scripts that match known loader patterns out of your pages and logs what it removed. If it can't check a page, it logs that too. The Content-Security-Policy limits where page scripts may connect, so an injected loader can't reach a blockchain endpoint. It starts in Report only mode, logs violations quietly with a cap, and you switch to Enforce when the log is clean.
Turn off the theme and plugin file editor, block PHP from running in uploads, disable XML-RPC and pingbacks, show a generic login error and send security headers. Hide user names covers the REST user list, ?author= lookups, author archives, the users sitemap and oEmbed author fields for logged-out visitors. Each is one switch, and all six are on by default. The security headers switch sits with the Content-Security-Policy settings.
Save a baseline when the site is clean. Later scans flag any code file that was added or changed, any new must-use plugin and any new administrator, so a backdoor that matches no known pattern still shows up.
The event log keeps the newest 200 events. It records new administrators, promotions to administrator, plugins activated or deactivated, theme switches and administrator logins. It also logs 10 failed logins in 10 minutes from one IP address, new must-use plugins, removed scripts, CSP violations and scan results. A scan runs every day, and e-mail alerts for medium and high events are there when you turn them on.
A lot of WordPress malware no longer sits in a file you can spot by name. It is a few lines of script injected into your pages, a post, an option or a must-use plugin, and it often shows its payload only to visitors.
One version reads its next stage from a public blockchain with a read-only eth_call, so there is no bad domain to block. Guardio Labs named this EtherHiding in their report of 13 October 2023 (checked 20 October 2026).
The payload is often a fake “Verify you are human” box that tells the visitor to paste a command into the Windows Run dialog. Microsoft calls this ClickFix in its analysis of 21 August 2025 (checked 20 October 2026). If your visitors report that page, our guide to the fake Cloudflare check on WordPress shows where the loader hides.
Google’s threat team counted about 14,000 web pages carrying one group’s injected loader by June 2025, placed in plugin files, theme files or the database (Google Threat Intelligence, 17 October 2025, checked 20 October 2026).
We wrote Security Guard after that kind of infection hit a production WordPress site. It runs on your own site, shows you what it found and what it did, and never uploads your files.
Install the plugin, then activate your licence so the site receives updates. Every feature works without the key. Installing an add-on and activating your licence has the steps.
On 20 October 2026 we planted an EtherHiding-style loader and a ClickFix clipboard script on a test site. With Remove injected scripts on, both came out of the page and each left a High line in the event log, while the theme’s own scripts stayed. On our development Mac the filter checked a page with 20 ordinary inline scripts in well under a millisecond and left it unchanged.
Scan data stays on your server, in a private folder with a random name and deny rules for Apache, LiteSpeed and IIS. The scan files hold no administrator e-mail addresses.
The event log keeps the newest 200 events. It records new administrators, promotions to administrator, plugins activated or deactivated, theme switches and administrator logins. It also logs 10 failed logins in 10 minutes from one IP address, new must-use plugins, removed scripts and scan results.
Content-Security-Policy violations go into the log quietly, without e-mails, and repeats are capped so a busy page can’t flood it. If the script filter can’t check a page, it logs that instead of skipping it silently.
A scan runs by itself every day. E-mail alerts for medium and high events are there, but off until you turn them on. Developers can run wp security-guard scan from the command line: it exits with code 1 when it finds anything High, so a deploy script can stop.
The Security Guard user guide covers every setting, and has a clean-up checklist for when the scan finds something. For the checks you can run by hand, without any plugin, read how to check if your WordPress site is hacked.
pre_user_query filter, because it asks WordPress for the user list. If the code that hides it arrived after you saved a baseline, the scan flags that file as added or changed.1.0.1
* If you used 1.0.0, save a new baseline after updating. The first scan after the update lists the PHP files in the WordPress root as added, because 1.0.0 did not record them.
* Scan data moves to a private, randomly named folder with deny rules for Apache, LiteSpeed and IIS. Your 1.0.0 baseline moves with it and the old folder is deleted.
* Scan files no longer store administrator e-mail addresses, and temporary scan files are deleted when a scan ends.
* Rescans come back clean once a problem is removed.
* The scan covers all of wp-content and every PHP file in the WordPress root, and each scan step stops after about 10 seconds.
* .htaccess and .user.ini files are checked line by line at any size, so padding cannot hide a handler line. The check covers AddHandler, AddType, SetHandler and ForceType (also inside Files and FilesMatch blocks), lines split with a backslash, RewriteRule lines with an H= or T= flag that names PHP, line breaks written as a lone CR, and auto_prepend_file. AddHandler cgi-script lines are not flagged, and the .htaccess in the plugin's own data folder is checked too. A file over 32 MB gets an "Oversized server config file" finding.
* Only one scan runs at a time: a second start shows "A scan is already running", and the daily scan skips that day.
* wp security-guard scan --format=json prints only JSON.
* The script filter checks scripts one at a time and logs when it cannot check a page, instead of skipping it silently.
* Content-Security-Policy reports are logged quietly with no e-mail and capped. Repeated filter removals are grouped, with at most one alert e-mail per rule every 30 minutes.
* "No PHP in uploads" also blocks .PHP, .php.jpg, .phtml and .phar files, and switching it off removes the whole block.
* "Hide user names from visitors" also covers ?rest_route=, every ?author= lookup, author archives and author feeds, the users sitemap and oEmbed author fields.
* The event log writes one row per new or promoted administrator, with the user name only.
* "Disable XML-RPC" also turns off pingbacks. "Generic login errors" also covers the lost-password form.
* E-mail alerts need a valid e-mail address, WP-CLI rejects bad flag values, and uninstall works on PHP builds without GLOB_BRACE.
1.0.0
* Initial release.
It keeps its data in WordPress options and its own folder in uploads, and never changes your other plugins' files.
Setup guides: Security Guard user guide
| WordPress on its own | With Security Guard | |
|---|---|---|
| Scan for injected-script malware | No | Yes: code, uploads, database, core files |
| See what changed since the site was clean | No | Yes: baseline of files, must-use plugins and administrators |
| Remove injected scripts from pages | No | Yes, and logged |
| Content-Security-Policy | No | Report-only or enforce, with violation log |
| Log new administrators and promotions to administrator | No | Yes, in the event log |
| Hardening switches | Manual edits | Six switches, on by default |
| Firewall | No | No |
| Malware clean-up | No | No: a report and a clean-up checklist |
You want a scanner that runs on your own site, tells you exactly what it found, and covers injected scripts, changed files and new administrators.
You need a firewall, two-factor login or automatic malware clean-up. This version has none of those.
No, it is not a firewall. It does not block requests before they reach WordPress. It finds malware and changes on the site, takes known injected scripts out of your pages and limits where page scripts can connect. Keep your firewall if you have one: the only clash we know of is a second plugin that also sends a Content-Security-Policy header.
No. It reports what it finds, with the file and line, the post, the option or the user, and you decide what to do. It never deletes or edits a file it flags, so it cannot break your site by removing the wrong thing. The user guide has a clean-up checklist.
Yes, when the script matches a known pattern. The scan and the script filter look for a clipboard write next to a shell command such as powershell, mshta or cmd /c. They also look for "verify you are human" text with Win+R or Ctrl+V steps, and for the blockchain calls EtherHiding loaders use. A newly written loader may not match until we add it, so save a baseline: it flags any code file that was added or changed.
No. The scan reads your files on your own server and keeps its results in a private folder there. The only outside requests are the core-file check, which fetches WordPress checksums from api.wordpress.org, and the licence and update checks, which send your licence key and site address to pluginsprout.com.
It can, if your pages load scripts or frames from other hosts or call other services from the browser. That is why it starts in Report only mode: nothing is blocked, and each violation goes into the event log quietly, without e-mails, with repeats capped. Add the hosts you use, then switch to Enforce. Inline scripts stay allowed, so theme and page builder code keeps running.
Not if the account is hidden by a pre_user_query filter, because Security Guard asks WordPress for the user list. It lists every administrator WordPress reports, flags administrators created in the last 30 days and any new since your baseline, and lists every must-use plugin. If the code doing the hiding arrived after you saved a baseline, the scan flags that file as added or changed.
High means a known malware pattern, a changed core file, PHP in uploads, or a new administrator or must-use plugin since the baseline. Medium is worth confirming, such as an obfuscated script or an administrator created in the last 30 days. Low and Info are facts to review, such as the administrator list. You can hide any finding you have checked.
It depends on your host and the number of files: about six minutes for 11,516 files on our development machine. The scan works in short steps, one request at a time, so it does not hit a server time limit.
We have not tested it on Nginx or multisite yet. The scan, baseline, script filter and Content-Security-Policy run in PHP and do not depend on the web server. Blocking PHP in uploads is an .htaccess rule for Apache and LiteSpeed, so on Nginx you add your own rule.
One licence key for 1, 5 or unlimited sites, whichever plan you bought: $49, $89 or $149 a year. Every feature works without a key; the licence delivers updates and support for the year. Refund terms are on the pricing page.