Does this CVE affect me?

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

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

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.

#Read the answer

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

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), 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:

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), the edge has shield 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:

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