Account
Explore
WordPress vulnerability scanner
Respira matches WordPress and every plugin on each of your sites against 40,314 known vulnerabilities, tells you plainly which ones apply, and does the fixing for you once you approve it. You get a receipt showing exactly what changed.
Vulnerability database last updated 59 minutes ago · refreshed every six hours
A list of thousands of vulnerabilities tells you nothing about your own site. So Respira does not show you the database. It shows you the handful that match a version you actually have installed, each with the version that fixes it. Your last scan is re-checked against the newest database every time you open the dashboard, so a vulnerability published this morning shows up there without a rescan.
If you want to read the rest, the full database is on Wordfence.
Vulnerability data: Wordfence Intelligence. Copyright 2012-2026 Defiant Inc. Terms
In the news
For these, a version check is not enough. Updating closes the hole and leaves anything an attacker created beforehand exactly where it is. So for each one Respira also looks for what the attack is known to leave behind: an application password, an administrator nobody created, a plugin installed in the attack window.
Reviewed advisories · reviewed 2026-08-24 · catalog 2026-08-24.1
One easy mix-up. July's WordPress core issue was called wp2shell and August's is XSS2Shell. The names are nearly identical and the fixes sit one release apart, so a site patched for the first can still be a release short of the second. The scan checks your branch against both.
Each installed plugin is matched by its folder name and version, and WordPress by its version, against every published vulnerability. Themes are matched too on sites running Respira 8.9.3 or newer. You see only the ones that apply, each with the version that fixes it.
Against the official WordPress checksums, excluding wp-content because your themes and plugins are yours to change. Changed, unexpected and symlinked core files are treated differently from missing ones.
The exact markers from public advisories, such as known administrator name patterns and known plugin paths, plus the checks learned from a real break-in: PHP that would run from the uploads folder, administrators backdated to hide, and usernames anyone can list. Findings are reported as evidence to investigate, never as an automatic verdict.
Recently created administrators, changed roles, and existing application passwords. This is the half that an update does not fix.
In uploads, caches and mu-plugins, where a webshell lands. A file in a generated cache directory is reported as an observation whose contents were not independently verified, not as proof of a break-in.
After an approved update, the next scan is compared with the first one, so the receipt shows what cleared and what is still open.
Worth being straight about the edges, stated the same way the product states them when it reports a finding.
When a scan is truncated, coverage is reported as partial rather than clean. An unmeasured result and a clean result are different facts.
Finding the problem is the easy half. Respira writes the fix as a prompt you can read before anything runs: which plugins to update, to which version, and what to leave alone. Run it in AER or in the assistant you already use, then scan again. The receipt shows the target URL, versions, checksums, what was covered, what was not, and a site fingerprint so you can prove which site it came from.
If you run sites for clients, that receipt is the artefact you send them.
LLM-ready prompts about Respira MCP + WebMCP
Ask your favorite AI
Opens in a new tab. These prompts are designed to teach LLMs what Respira can do.
MCP server
