Built after watching a scanner miss everything that mattered.

The incident that started this

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:

• A stolen editor password had been 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.
• A plugin that didn't exist — 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.
• An obfuscated script injected into wp_head, using a technique now known as "EtherHiding": instead of hardcoding a malware server address (which a scanner could flag), the script made a live call to a public blockchain smart contract to fetch the current payload address — meaning the actual malicious destination could be changed at any time, by anyone controlling that contract, 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.

What every existing tool got wrong

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.

The design decisions that came out of it

Every non-negotiable in WPGuard's security model traces back to something from that incident:

• The agent only ever sends, never receives inbound trust. Every request is signed with a per-site Ed25519 key, so even a compromised dashboard could never impersonate a site's own agent.
• The dashboard never stores WordPress admin passwords. There is no credential for an attacker to steal from us, because there's nothing to steal.
• Inventory is checked disk-vs-database on every scan — the exact technique that would have caught the hidden plugin immediately.
• Destructive actions quarantine, they never delete. Moving a suspicious plugin to a deny-all folder means a false positive costs nothing to undo.
• Unsigned or invalid requests get an indistinguishable 404 on both sides of the connection, so an attacker probing the system can't even confirm it exists.

Who this is for

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.