How ShieldWave works, and how to check it
A security plugin asks for a lot of trust: it reads every file on your site. This page states what ShieldWave Security does, what it never does and exactly what leaves your server, with a way to verify the parts you should not have to take on faith.
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.
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. That comparison is the only outside request 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
It never edits, moves or deletes your files, users or settings.
It stores only its own data: settings, scan results, history and a file baseline, plus, for accounts that turn on two-factor login, the authenticator secret (stored encrypted, with a key derived from your site’s own salts, when your server’s PHP has libsodium; a server without it keeps the secret readable, and the plugin’s settings say so) and the recovery codes (kept only as hashes). Every fix is explained in plain words for you, your developer or your host to apply.
It adds nothing to the pages your visitors see.
Visitors get no ShieldWave scripts, styles, badges or tracking. Only a signed-in administrator sees its item in the WordPress toolbar.
It makes no outside request when it is activated or when admin pages load.
Requests happen when a scan runs, when you use an account action, and on a schedule only for the optional services you turn on: the threat feed and vulnerability updates every few hours, the account check-in hourly.
Two features act on sign-ins, and neither changes anything stored.
Login protection refuses logins from one address for a short cooldown after repeated failures. Two-factor login asks for a code from your authenticator app, only for accounts that turned it on.
What leaves your server
| Service | What is sent | Never sent |
|---|---|---|
| WordPress.org checksumsWhen a scan runsOn by default | Your WordPress version and language, and the folder name and version of each plugin and theme, to fetch their official checksums. | File contents. Like WordPress’s own update checks, these requests carry your site address in the user agent. |
| Vulnerability lookupWhen that check runsOpt-in | Your WordPress version, and the folder name and version of each installed plugin and theme, premium ones included. | Your site address, an account or any personal data. |
| Threat feedAbout every three hoursOpt-in | Nothing about your site. The plugin downloads a signed file; the request says only which plugin version is asking. | Anything about your site. |
| AI second opinionOnly for a file the rules cannot judgeOpt-in | A redacted excerpt of that file, its fingerprints, your admin language and a salted hash that stands in for your site. | Your site address, email addresses, passwords, keys or tokens, and configuration files such as wp-config.php. |
| ShieldWave accountOnly after you connect oneOpt-in | This site’s id and address, scan results and the list of installed plugins and themes, so the dashboard can show them. | Posts, pages, comments, user names, email addresses or passwords. |
Requests to ShieldWave identify themselves as ShieldWave-Security/1.0.2 (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:
- The document is signed with Ed25519 over the bytes
shieldwave-intel-v1\nfollowed by the payload, and the signature verifies against the public key built into the plugin. - 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.
- Its version is not older than the one the site already has, so an old feed cannot be replayed.
- 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.
- Algorithm
- Ed25519
- Public key (base64)
- B2PRMUPcLPijkr6jqD/rGhoOqhPpqM1N4NGPto8rs+w=
- SHA-256 of the key
- 8fd2b0e2 b65c1bf1 1ae0dfbf 3a0d977b b911f9be 17dddfb0 615c227f 0a6b4356
- Feed address
- https://shieldwave.io/api/plugin/intel
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; - database credentials, keys, salts and secrets in configuration constants, values 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.
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 web application firewall: it does not inspect and block every request to your site.
- It does not remove malware for you. It finds it, explains it and tells you what to do.
- It cannot protect a site from someone who already has an administrator account.
- Login protection sees the address of the connection. Behind a proxy or CDN that is the proxy’s address, so a lockout there applies to everyone arriving through it; keep such sites on a short lockout, or add your own address to the trusted list.
- 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.
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.