WPGuard isn't a feature someone brainstormed in a roadmap meeting. It exists because a real client site was compromised in a way that every existing tool we tried would have missed — and we decided that wasn't acceptable to keep happening to the sites we're responsible for.
A WordPress developer managing sites for several clients noticed one site behaving strangely. On investigation, three things had happened at once, over weeks, without a single alert firing anywhere:
Escalated to a full administrator account, then used to log in from three different IP addresses within the same minute — each one presenting a Googlebot user-agent, specifically to blend into normal traffic logs.
At least, not according to wp-admin. It used WordPress's own all_plugins filter to remove itself from the plugin list any time an administrator viewed it, while remaining fully active on disk.
Injected into wp_head using a technique now known as "EtherHiding": rather than hardcoding a malware server address a scanner could flag, it called a public blockchain smart contract to fetch the current payload address — changeable anytime, without ever touching the compromised site again.
Alongside all of that sat the kind of mundane leftovers that make an attacker's job easier in the first place: an exposed Duplicator installer script, a 112MB debug log sitting in a public directory, a plugin folder with 777 permissions, and a known-vulnerable plugin that had simply been deactivated instead of removed.
None of this was exotic. It was invisible for one simple reason: every scanner and security plugin available checks what's happening right now, on demand, from inside the same compromised WordPress install an attacker could also control. A plugin that hides itself from all_plugins hides from a scanner that calls all_plugins. A login from a "Googlebot" doesn't look unusual to a plugin that only flags known bad IPs.
What was actually needed was something structurally different: an agent that reports continuously rather than scanning on demand, that compares what's on disk against what WordPress itself reports (exactly the mismatch a hiding plugin depends on), and a dashboard that lives entirely outside the site being monitored — so that even a fully compromised WordPress install can't reach back in and silence its own alarm.
Every non-negotiable in WPGuard's security model traces back to something from that incident — the full technical writeup lives on the Security page:
Every request is signed with a per-site Ed25519 key, so even a compromised dashboard could never impersonate a site's own agent.
There is no credential for an attacker to steal from us, because there's nothing to steal.
The exact technique that would have caught the hidden plugin immediately.
Moving a suspicious plugin to a deny-all folder means a false positive costs nothing to undo.
On both sides of the connection, so an attacker probing the system can't even confirm it exists.
WPGuard is built for the developers and agencies who are the ones actually on the hook when a client site gets hacked at 2am — not a security team with a budget for an enterprise platform, but the person who has to explain what happened and fix it themselves. Per-site pricing exists because that's how this work already gets billed: some sites are worth more attention and more money than others, and the tool should reflect that instead of forcing everyone into one flat rate. See the Pricing page for the exact numbers.
Connect a site in a few minutes and get your first inventory scan back immediately.
Get started →