Account
Explore
Free · no plugin · no login
Respira's free WordPress vulnerability scanner checks a site from its public pages. Enter an address and it reads the WordPress version and the plugins and themes those pages name, then matches every version it can read against 43,747 known vulnerabilities from the Wordfence Intelligence database. Nothing to install, no login, and nothing on the site is changed. It is a known-vulnerability check, not a malware scan.
21 October 2026: two critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619) let anyone run code on a server with no login. Every WordPress site runs on PHP. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and only your host can install it. When a server shows its PHP version, the scan below says whether it carries the fix. What to check and what to ask your host
A free account adds the full list with CVEs and fixed-in versions, a fix prompt to paste into ChatGPT or Claude, and a weekly re-check. Respira for WordPress goes further: it scans from inside each site, sees every installed plugin with its exact version, and does the fixing once you approve it, with a receipt showing exactly what changed.
Vulnerability database last updated 2 hours ago · refreshed every six hours
Security across your sites
2 need an update, 1 has something to check, 3 are clear.
MCP server
brightbakery.com
WordPress6.9.4
WooCommerce—
Plugins21
Core filesVerified
Update needed6 min ago
03updates01to check once
1 note
DetailsClose
6.9.4→6.9.7
August 2026 core security release (XSS2Shell) CVE-2026-64638
12 August 2026 core security release CVE-2026-65640
Updating closes the hole. It cannot show whether anything was changed before the patch landed, so look once at application passwords and recently added administrators, then mark it reviewed.
thecopperkettle.co
WordPress6.9.7
WooCommerce—
Plugins14
Core filesVerified
Update needed6 min ago
01update
no backup plugin
DetailsClose
The real page lists each item here with the version that fixes it and a button that runs the update once you approve it.
fernhollow.shop
WordPress6.9.7
WooCommerce10.1
Plugins33
Core filesVerified
Something to check6 min ago
01to check once
DetailsClose
The real page lists each item here with the version that fixes it and a button that runs the update once you approve it.
meridian-dental.com
WordPress6.9.7
WooCommerce—
Plugins18
Core filesVerified
All clear7 min ago
Nothing to do
DetailsClose
No known vulnerability matches a version installed here, core files match the official checksums, and nothing is waiting for a look.
ottersandco.com
WordPress6.9.7
WooCommerce—
Plugins9
Core filesVerified
All clear7 min ago
Nothing to do
DetailsClose
No known vulnerability matches a version installed here, core files match the official checksums, and nothing is waiting for a look.
saltandsteam.co
WordPress6.9.7
WooCommerce—
Plugins12
Core filesVerified
All clear7 min ago
Nothing to do
1 note
DetailsClose
No known vulnerability matches a version installed here, core files match the official checksums, and nothing is waiting for a look.
A scan reads your sites and changes nothing. If the vulnerability database cannot be reached, the result is reported as unknown, never as clean.
The free scan takes the steps a careful person would take by hand, and it is done within 20 seconds.
Type the address of any WordPress site into the form at the top of this page, such as example.com. There is no account to create and nothing to install.
It requests the page, the RSS feed when the page hides the WordPress version, the public readme.txt of each plugin the page names (up to 40) and the style.css of each theme. It never guesses folder names, never logs in and stops after 20 seconds.
The WordPress, plugin and theme versions it can read are matched against the Wordfence Intelligence vulnerability database, refreshed every six hours. Anything without a readable version is listed as not checked, never as safe.
You see which components have known vulnerabilities and the severity of the worst one. A free account adds every record with its CVE and the version that fixes it, a fix prompt, and a weekly re-check.
Update each component to the fixed version the result names, or deactivate it while no fix is published, then run the scan again to confirm it cleared.
An outside scan sees what a site shows the public. A scan from inside the site sees everything installed. Here is what changes at each step.
| Check | Free scan | Free account | Respira for WordPress |
|---|---|---|---|
| Where it looks | Public pages only | Public pages only | Inside the site |
| Plugins and themes checked | The ones the pages name, with a readable version | The ones the pages name, with a readable version | Every installed one, active or not, with its exact version |
| What you see | Affected components and the worst severity | Every record, its CVE and the version that fixes it | Every record, its CVE and the version that fixes it |
| The fix | Not included | A fix prompt for ChatGPT, Claude or a developer | The update runs once you approve it, with a receipt |
| Checked again | When you run it again | Every week, up to 25 sites | Re-matched against the newest data whenever you open the dashboard |
| Core checksums, PHP in uploads, admin accounts, hidden plugins, rewrite rules | No | No | Yes |
| Price | Free, no login | Free | 7-day free trial, then a paid plan |
Running one of the free plugins, Inhale or Respira ARC? Connect it to a free account and the weekly check runs from inside the site, so it sees every installed plugin and theme with its exact version.
A security report that lists everything it knows is hard to act on. Respira sorts each site into one of four states, puts the ones that need something at the top, and keeps the detail folded until you open it. Advice about your server, such as PHP being allowed to run from the uploads folder, is labelled advice and never colours a site red.
A trace worth confirming by eye: a plugin that hides itself, a changed core file, an administrator nobody created. It is rare, and it is the only state shown in red.
A version installed on the site has a known vulnerability, and a newer version closes it. The fix is one approval away.
The site is patched. One look at what a version number cannot show, such as application passwords, then it is closed for good.
Nothing known matches what is installed, core files match the official checksums, and nothing is waiting.
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 Attack risk: EPSS by FIRST, the chance of exploitation attempts in the next 30 days.
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-11-05 · catalog 2026-11-05.1
The newest one is in the WordPress updater. CVE-2026-119977, fixed in WordPress 7.1.4 on 28 October 2026, lets anyone with no login take over a site during the seconds a core update unpacks, and CISA added it to its list of actively exploited flaws on 3 November. The update to 7.1.4 still runs the old updater, so ask your host to block web access to wp-content/upgrade before updating. The scan checks your branch against its patch, and the full scan lists the administrators created since 28 October.
The one before it is not in WordPress at all. On 21 October 2026 PHP itself shipped fixes for CVE-2026-109618 and CVE-2026-109619, two flaws that let anyone run code on a server with no login. No WordPress update or plugin closes them; the host has to update PHP. The scan reads the PHP version when the server shows it, and the full scan checks for what an attacker would leave behind. The PHP flaws, the fixed versions and the message to send your host.
One easy mix-up. July's WordPress core issue was called wp2shell, August's was XSS2Shell, and September had two: Click2Shell on the 17th, and CVE-2026-87902 on the 22nd, which is being exploited against live sites. October's 7.1.4 fixed CVE-2026-119977, exploited too. Each fix sits one release above the last, so a site patched for one of them can still be a release short of the next. The scan checks your branch against every one of them.
Written up in full, with the branch tables and what to check after updating: Click2Shell and the 17 September core release, how to check and fix wp2shell, and the September 2026 plugin vulnerabilities on software most sites actually run, including the one no version number can fix.
The free scan stops at what the public pages show. With Respira for WordPress connected, the scan runs from inside the site and checks all of this.
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.
The plugins WordPress is actually running are compared with what the Plugins screen shows and with the files on disk. A plugin that is active and not listed is reported, and so is an active file that carries no plugin header. Needs Respira 9.1.10 or newer.
A rule that sends your page addresses somewhere no plugin on the site accounts for is reported together with the pages it shadows. That is how one hidden plugin made a site's legal pages answer "not found" without touching a single page.
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.
Each of these does something this scanner does not, and the honest answer is often to run one of them alongside it.
Where Respira differs: the first check needs no install and no access, it names the version that fixes each problem, and it carries on to the fix. A free account writes the fix as a prompt you can read before anything runs. With Respira for WordPress the update itself runs once you approve it, and ends in a receipt. If you need a firewall or a malware cleanup, use a tool built for that.
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.
Some findings have no update to install. A plugin that should not be on the site can be quarantined once you approve it: switched off without running its own code, moved out of the plugins folder, with every file kept as evidence and one step to put it back if it turns out to be yours. A site cleaned that way is written up in a plugin that was running and not in the plugin list.
If you run sites for clients, that receipt is the artefact you send them.
Every WordPress site runs on PHP, so it is affected until its server runs a fixed PHP. The PHP project fixed CVE-2026-109618 and CVE-2026-109619, two critical remote code execution flaws in PHP itself, on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.1 and older get no fix from the PHP project. The free scan shows the PHP version when the server reveals it in its headers; most hide it, so check Tools, then Site Health, then Info, then Server, in WordPress.
No. The flaws are in PHP, which reads the request before WordPress or any plugin loads, so only updating PHP fixes them. That is your host's job, or yours if you run the server. Respira cannot update PHP either. What it can do is tell you which PHP a site runs, give you the message to send your host, and, once connected, check the site for what an attacker would leave behind: PHP files in uploads, changed core files, new administrators and application passwords.
Ask them to update the PHP that serves your site to the fixed release for its branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or newer, to confirm the fix is included if they run a distribution or long-term support build, and to tell you which interim settings from the php.net advisory are in place if they cannot update today. The blog post on this page has a message you can copy.
Yes. The public scan is free and needs no login. A free respira.press account adds every record with its CVE and the version that fixes it, a fix prompt, and a weekly re-check of up to 25 sites. Only the full scan from inside the site, part of Respira for WordPress, is paid, after a 7-day free trial.
No. The scanner reads the site from outside, the way a browser does, so there is nothing to install and no access to give. The trade-off is that it sees only what the public pages show. For a check from inside the site, the free Inhale and ARC plugins can connect to a free account, and Respira for WordPress runs the full scan.
The WordPress version and the plugins and themes the site's pages name, each matched by version against 43,000+ known vulnerabilities from the Wordfence Intelligence database, refreshed every six hours. It reads the page source, the RSS feed when needed, each named plugin's public readme.txt and each theme's style.css. It does not guess folder names, try logins or send attack payloads.
As accurate as the versions it can read. A version from the WordPress generator tag or a plugin readme.txt is usually right; one read from an asset address can be wrong, and the result says where each version came from. Components with no readable version are listed as not checked. A clean result means nothing known matched the versions that were readable, not that the site is safe.
No. The public scan reads version numbers. It does not look for malware, injected code or backdoors, and a site can be infected while running current versions. The full Respira scan, run from inside the site, checks WordPress core files against the official checksums, PHP files in the uploads and cache folders, administrator accounts and application passwords, plugins that hide from the Plugins screen, and rewrite rules that take over pages. It is not a signature-based malware scanner, so a confirmed infection still calls for a cleanup service.
Wordfence is a plugin you install, with a firewall and a malware scanner; this scanner uses the same Wordfence Intelligence vulnerability data without an install. WPScan is a command-line tool and API. Sucuri SiteCheck looks mainly for malware and blocklisting visible from outside. Respira answers one question, which versions on the site have known vulnerabilities and which version fixes each one, and then helps you apply the fix.
Take a backup, then update the affected plugin, theme or WordPress to the fixed version the result names. If no fix is published, deactivate it until one is. Then check what an update does not undo: administrators and application passwords you do not recognise, recently installed plugins, and PHP files in uploads. Run the scan again to confirm. A free account gives you a fix prompt to paste into ChatGPT or Claude, or to send to your developer.
No. It makes a handful of ordinary page requests, the same kind a browser makes: the page, sometimes the feed, and at most 40 plugin readme files and 6 theme stylesheets. It never logs in, submits a form or tries an exploit, and it stops after 20 seconds.
Compare the version of each installed plugin, and of WordPress itself, with the published vulnerability records for that software. Respira does this on every scan against the Wordfence Intelligence database, refreshed every six hours, and lists only the vulnerabilities that apply to the versions installed, each with the version that fixes it.
Compare your WordPress version against the patched release for your branch: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15 or 6.1.16, with backports down to 4.7.39. Below your branch patch means you are missing the 28 October 2026 security release, which fixes CVE-2026-119977: while a core update unpacks, anyone with no login can reach the installer in wp-content/upgrade and take over the site. It is being exploited, and CISA added it to its Known Exploited Vulnerabilities catalog on 3 November 2026. The update to the fixed release still runs the old updater, so ask your host to block web access to wp-content/upgrade before you update. If your site updated on or after 28 October, check for administrators you did not create.
Compare your WordPress version against the patched release for your branch: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13 or 6.1.14, with backports down to 4.7.37. Below your branch patch means you are missing the 22 September 2026 security release, which fixes CVE-2026-87902: with no login, an attacker can make WordPress load a PHP file from outside the active theme, and run code on the server when the theme and the server meet further conditions. It is being exploited against live sites, and CISA added it to its Known Exploited Vulnerabilities catalog on 25 September 2026. The 17 September patches do not cover it.
Compare your WordPress version against the patched release for your branch: 7.1.1, 7.0.5, 6.9.8, 6.8.9, 6.7.8, 6.6.8, 6.5.11, 6.4.11, 6.3.11, 6.2.12 or 6.1.13, with backports down to 4.7.36. Below your branch patch means you are missing the 17 September 2026 security release, which fixes eleven issues. Two carry the news: a forced theme install and preview that researchers chain to code execution and call Click2Shell, and an unauthenticated stored cross-site scripting flaw in wpautop() tracked as CVE-2026-93485. WordPress rates its own fix for the forced install medium; the higher figure quoted in the press is the researchers' rating for the full chain, which also needs a logged-in administrator to open a crafted link and a theme whose own handler runs the attacker's code. The August patches do not cover this release. A newer core security release shipped on 28 October 2026: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15 or 6.1.16, with backports down to 4.7.39. A site on the Click2Shell patch still needs that one to be current.
Compare your WordPress version against the patched release for your branch: 7.0.3, 6.9.6, 6.8.7, 6.7.6, 6.6.6, 6.5.9, 6.4.9, 6.3.9, 6.2.10, 6.1.11 or 6.0.13, with backports down to 4.7.34. If you are below your branch patch you are missing the 6 August 2026 security release. Being patched for the earlier wp2shell chain is not enough, because those patches sit one release lower on every shared branch. A newer core security release shipped on 28 October 2026: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15 or 6.1.16, with backports down to 4.7.39. A site on the XSS2Shell patch still needs that one to be current.
Compare the active plugins stored in the database with what the Plugins screen lists and with the folders in wp-content/plugins. A plugin that is active in the database and missing from the screen is hiding itself. Respira runs that comparison on every scan from plugin version 9.1.10, reports the plugin, and can quarantine it once you approve: switched off without running its own code, moved out of the plugins folder, with its files kept as evidence.
A vulnerable version means the site could be taken, not that it was. Updating closes the hole but does not undo a break-in. Check for application passwords you do not recognise, administrators created recently, plugins installed recently, and unexpected PHP files in uploads and mu-plugins.
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.
