# Does this CVE affect me?

> Look up a CVE or GHSA in its public sources and see which of your proxied sites it may affect, with MCP, the CLI or the API, and how to read the answer.

When a new vulnerability is published, two questions come first: is it real and serious, and which of my sites run the affected software? OpenWAF answers both. The lookup reads the CVE or GitHub advisory from its public sources (cve.org, CISA KEV, FIRST EPSS, GitHub advisories, NVD). The exposure check compares it with every proxied site of your organization and tells you what the edge already does against it.

Both are read-only and available to every role. A token limited to a client or to a zone only sees its own sites.

## Ask

**MCP**


Ask your assistant, for example «Does CVE-2026-111497 affect any of my sites?». It calls two tools:

1. `vuln_lookup` with `{"id": "CVE-2026-111497"}`: the record, CVSS, affected versions, KEV and EPSS. If `exists` is `false`, the id is not known to its sources: stop there.
2. `vuln_exposure` with `{"id": "CVE-2026-111497"}`: one row per proxied site, with the match, the confidence, the evidence and the state of the edge mitigation.

**CLI**


```sh
openwaf-cloud ctl vulns show CVE-2026-111497
openwaf-cloud ctl vulns exposure CVE-2026-111497
```

Add `--json` for the full API answer. The token comes from `OPENWAF_TOKEN` or `OPENWAF_TOKEN_FILE`.

**curl**


```sh
curl -s "https://dash.openwaf.dev/v1/vulns/CVE-2026-111497" \
  -H "Authorization: Bearer $OPENWAF_TOKEN"

curl -s "https://dash.openwaf.dev/v1/orgs/$OPENWAF_ORG/vulns/CVE-2026-111497/exposure" \
  -H "Authorization: Bearer $OPENWAF_TOKEN"
```



Ids are CVE (`CVE-2026-12345`) or GitHub advisory (`GHSA-xxxx-xxxx-xxxx`) ids, in any case. The full fields are in the [API reference](https://developers.openwaf.dev/api/vulnerabilities/).

## Read the answer

Each site gets a `match`, a `confidence` from 0 to 1 and the `evidence` behind it:

| `match` | Meaning | `confidence` |
|---|---|---|
| `affected` | The affected product was seen and its version is inside an affected range. | 0.9 when the version comes from a generator tag or a header; 0.7 when it comes from a `?ver=` hint. |
| `posible` | The product was seen, or the site's `stack` setting says it runs it, but the version is not visible or not comparable. | 0.5 when the product was seen; 0.3 when only the `stack` setting says so or the homepage could not be read. |
| `no_detectado` | Nothing on the homepage points to the affected product or version. | 0.9 for a WordPress plugin on a site that is not WordPress; 0.8 when the version is outside the range or the CMS or framework was not seen; 0.6 for a WordPress plugin the homepage does not load; 0.5 for server-side products; 0.2 when the site has no fingerprint yet. |

`versions` lists what was seen (for example `{"wordpress": "6.6.2", "plugin:woocommerce": "9.3.1"}`), `fingerprinted_at` when, and `fingerprint_via` whether the homepage was read through the edge (`edge`) or from your origin (`origin`). `summary` counts the sites per `match`.

Start with `affected`, then `posible`. For each one, check the version on the server itself and patch.

## How sites are judged

The check is passive. OpenWAF never scans your sites, sends exploit payloads or crawls pages. It uses two things:

- **The site's `stack` setting** (`wordpress`, `nextjs`, `generic`, `static`).
- **A fingerprint of its homepage, refreshed once a day.** The control plane makes one `GET https://<host>/` as a visitor, through the edge, with the User-Agent `OpenWAF-Fingerprint/1 (+https://openwaf.dev; …)`. If the edge answers with a challenge, a block or an error (for example in [under attack mode](https://developers.openwaf.dev/waf/under-attack/)), it makes one `GET /` to the site's origin with the site's `Host` header instead. Origins on private addresses are never contacted. Redirects are not followed and at most 2 MiB are read. `robots.txt` is not consulted: it is your own site, the request is a single identified homepage request per day, and it is not crawling.

From the homepage it extracts `<meta name="generator">` (WordPress version, WooCommerce, Elementor…), the WordPress core version from its block library and emoji assets, the plugin and theme slugs of `/wp-content/plugins/<slug>/` and `/wp-content/themes/<slug>/` with their `?ver=`, the `Server` and `X-Powered-By` headers (CDN and edge servers are ignored), `X-Nextjs-*` headers and the Next.js (`/_next/static/`, `__NEXT_DATA__`) and Nuxt (`/_nuxt/`, `__NUXT__`) markers. Next.js, Nuxt and Express imply Node.js.

The vulnerability is matched by product:

- **WordPress plugins and themes** by their wordpress.org slug, taken from the record's package or from its Wordfence, Patchstack, WPScan or wordpress.org references.
- **Other products** by name or CPE product: WordPress, Next.js, Nuxt, Express, Node.js, PHP, nginx, Apache HTTP Server, LiteSpeed, OpenResty, IIS, Caddy, Drupal, Joomla and others.

Version ranges are compared when they can be parsed (CVE JSON 5 ranges, GHSA ranges such as `>= 1.0, < 1.2.1`, NVD CPE ranges).

## Limits

- **`no_detectado` does not mean «not affected».** It means the homepage shows nothing that matches. A server-side library, a backend behind the site or a component that leaves no trace in the HTML is invisible to this check.
- **`?ver=` is a hint.** Plugins often use their own version there, but not always; a `?ver=` equal to the WordPress version is ignored.
- **Plugins that only load in `/wp-admin` are invisible.** The homepage only shows the plugins that load on it.
- **A new site has no fingerprint until the next daily run** (`fingerprinted_at: null`, confidence 0.2).

**Tip:** set the site's `stack` setting (`stack=wordpress`, `stack=nextjs`). Sites whose homepage cannot be read, or that hide their technology, then still count as `posible` for vulnerabilities of that stack. In the dashboard: **Security → Firewall → Application**; with the CLI:

```sh
openwaf-cloud ctl zones set example.com stack=wordpress --reason "WordPress site"
```

## Edge mitigations

When the edge has a protection for a vulnerability, the answer lists it in `mitigations` and shows its state on each site. For [CVE-2026-111497 (Node2Shell)](https://developers.openwaf.dev/waf/cve-2026-111497/), the edge has [shield](https://developers.openwaf.dev/waf/shields/#brotli-request-body) **1009 «Brotli Request Body»**, which refuses request bodies with `Content-Encoding: br`, and every Node.js backend is flagged `posible`. Each site's `mitigations[].state` is:

| `state` | Meaning |
|---|---|
| `active` | The shield blocks on this site. |
| `log_only` | The WAF is in `log` mode: the shield only records, requests reach the origin. |
| `off` | The WAF is `off`: the shield doesn't run. |
| `exempt_paths` | A [WAF exception](https://developers.openwaf.dev/waf/waf-exceptions/) for rule 1009 switches it off on the paths in `exempt_paths`. |

An edge mitigation reduces the risk; it doesn't patch your servers. Patch them as the advisory says.