How ShieldWave works, and how to check it

What runs on your site

The checks run inside WordPress, on your own server: malware analysis of files that WordPress.org cannot vouch for, file integrity, file changes against a recorded baseline, uploads, injected content, exposed files, accounts and configuration. Scans run in the background in short steps, never while a visitor’s page is being built. On a visitor’s request ShieldWave only registers its hooks and, with login protection on, checks for the ?author= trick. While the site is connected to a ShieldWave account (plugin 1.1.0 and later), it also prints one invisible tag, <meta name="shieldwave-verify">, on the home page, which lets shieldwave.io confirm that the domain is yours.

To prove that a core, plugin or theme file is untouched, ShieldWave compares it with the official checksums WordPress.org publishes, the same service WordPress uses for its own updates. During a scan it also asks WordPress.org for theme packages, plugin information and the list of WordPress releases. Those requests to WordPress.org are the only outside requests a default install makes. Everything else that leaves your server is off until you turn it on, and is listed below.

What it never does on its own

What leaves your server

Requests to ShieldWave identify themselves as ShieldWave-Security/1.1.30 (the number is the installed version). WordPress adds your site address to every outgoing request by default. ShieldWave replaces that with a neutral value, because a service that promises not to know your site should not receive its address in a header. Like any web request, each one still comes from your server’s IP address.

The threat feed is signed. Check it yourself.

Detection rules decide what the scanner flags, so a forged feed could hide real malware or raise false alarms. That is why the plugin accepts a feed only when all of these hold:

1. The document is signed with Ed25519 over the bytes shieldwave-intel-v1\n followed by the payload, and the signature verifies against a public key built into the plugin.
2. It has not expired. A feed is valid for seven days. After that its rules stop applying at once; its lists of known good and bad files are kept seven more days, then dropped.
3. Its version is not older than the one the site already has, so an old feed cannot be replayed.
4. Every rule and list stays within fixed size and pattern limits; anything outside them is dropped.

The key is published here and ships inside the plugin (SHIELDWAVE_SIGNING_KEYS in shieldwave-security.php), so you can compare the two. Since 1.1.30 the plugin also pins a second public key, kept offline for the day the first key is lost (SECOND_PUBLIC_KEY in includes/class-signature.php).

A short script does the same check as the plugin, with the key pinned inside it rather than fetched from us. It needs Node.js 18 or newer and has no dependencies.

# download the verifier, read it, then run it
curl -O https://shieldwave.io/verify/shieldwave-verify-feed.mjs
node shieldwave-verify-feed.mjs

It prints whether the signature is valid, the key fingerprint, when the feed was issued and expires, and exactly what it holds right now: rules, overrides and file fingerprints. Change a single byte of a saved copy and run it on the file to see the check fail.

The AI second opinion, precisely

It is off until you turn it on, and it is used only for a file the local rules cannot judge on their own. Before anything leaves your server, the excerpt is cut to the lines around the suspicious code, at most 6,000 characters, and cleaned:

• your site’s host names become example.com;
• email addresses become user@example.invalid;
• IPv4 addresses become 0.0.0.0 and IPv6 addresses ::ip-redacted;
• the path of your WordPress folder becomes /path/to/wordpress, and home folders become /home/user or /Users/user;
• every DB_ constant, constants with key, salt, secret, pass or token in their name, the arguments of database connections, values of 6 characters or more assigned to names like key, token, secret or password, well-known token formats and long hexadecimal strings become [redacted];
• very long strings are shortened so the structure survives but the content does not.

Other web addresses stay. If any step fails, nothing is sent. Files named wp-config or .env with any ending, .htpasswd, .user.ini, php.ini or auth.json, backup copies, database dumps (.sql), logs and .ini files are never read for an opinion. Plugin versions before 1.1.10 removed only host names, email addresses, passwords and keys.

Your site is identified only by a salted hash that cannot be turned back into its address. The excerpt is reviewed by a language model run by our AI provider, a US company, passed as material to analyse and guarded against instructions hidden in the code. The verdict is stored by the file’s fingerprint and reused when the same file shows up on another site.

What it is not

• It is not a cloud web application firewall. Its optional request firewall, off until you turn it on, checks requests on your server with local rules that ship with plugin updates, and sends no request data anywhere. A blocked request has still reached your server. The optional edge rules use your own Cloudflare zone and plan, and cover only flaws for which the feed has a rule.
• It cannot stop flaws in PHP itself, such as php2shell (CVE-2026-109618 and CVE-2026-109619), which run before any plugin loads, and the feed has no edge rule for php2shell. Updating PHP is the fix. When the site’s PHP is below the fixed release, the plugin warns administrators at once. The warning reads the version number only, so it asks you to check with your host. On PHP-FPM and LiteSpeed under Linux, a notice says when the PHP process serving the page still runs a file replaced on disk, which usually means PHP was updated without a restart. It checks only that one process and does not show whether the fix is installed.
• It does not clean a hacked site for you. It finds malware, explains it and tells you what to do. Code injected into a theme, a custom plugin, uploads, posts or options it removes only after you approve each change.
• It cannot protect a site from someone who already has an administrator account.
• Login protection counts the address of the connection, never a header a request can fake. Behind a proxy or CDN that is the proxy’s address until you list the proxy’s addresses as trusted and pick the header that carries the visitor’s address. Without that, a lockout applies to everyone arriving through the proxy.
• A check that could not run, for example because WordPress.org did not answer, is reported as not run. It is never counted as passed.

This page is about the plugin that runs inside your WordPress. The ShieldWave scanner that checks a site from the outside keeps to a set traffic budget and slows down or stops if a server is under strain. How that works is set out on How ShieldWave scans a live site.

Found a problem?

If something here is wrong, or you find a security issue in ShieldWave itself, please follow the vulnerability disclosure policy. The exact plugin package this page describes is at shieldwave.io/api/plugin/download; it is licensed under the GPL, so every claim here can be checked against its source.