# ¿Me afecta este CVE?

> Consulta un CVE o GHSA en sus fuentes públicas y qué sitios con proxy puede afectar, con MCP, la CLI o la API, y cómo leer la respuesta.

Cuando se publica una vulnerabilidad nueva, hay dos preguntas primero: ¿es real y grave?, y ¿cuáles de mis sitios usan el software afectado? OpenWAF responde a las dos. La consulta lee el CVE o el aviso de GitHub en sus fuentes públicas (cve.org, CISA KEV, EPSS de FIRST, avisos de GitHub, NVD). La comprobación de exposición lo compara con cada sitio con proxy de tu organización y te dice qué hace ya el borde contra él.

Las dos son de solo lectura y están disponibles para todos los roles. Un token limitado a un cliente o a una zona solo ve sus sitios.

## Pregunta

**MCP**


Pregunta a tu asistente, por ejemplo «¿Me afecta CVE-2026-111497 en alguno de mis sitios?». Llama a dos herramientas:

1. `vuln_lookup` con `{"id": "CVE-2026-111497"}`: el registro, el CVSS, las versiones afectadas, KEV y EPSS. Si `exists` es `false`, sus fuentes no conocen el id: para ahí.
2. `vuln_exposure` con `{"id": "CVE-2026-111497"}`: una fila por sitio con proxy, con la coincidencia, la confianza, las pruebas y el estado de la mitigación del borde.

**CLI**


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

Añade `--json` para la respuesta completa de la API. El token sale de `OPENWAF_TOKEN` o de `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"
```



Los ids son de CVE (`CVE-2026-12345`) o de aviso de GitHub (`GHSA-xxxx-xxxx-xxxx`), en mayúsculas o minúsculas. Todos los campos están en la [referencia de la API](https://developers.openwaf.dev/es/api/vulnerabilities/).

## Lee la respuesta

Cada sitio recibe un `match`, una `confidence` de 0 a 1 y las pruebas (`evidence`) que la justifican:

| `match` | Significado | `confidence` |
|---|---|---|
| `affected` | Se vio el producto afectado y su versión está dentro de un rango afectado. | 0,9 si la versión sale de una etiqueta generator o de una cabecera; 0,7 si sale de una pista `?ver=`. |
| `posible` | Se vio el producto, o el ajuste `stack` del sitio dice que lo usa, pero la versión no se ve o no se puede comparar. | 0,5 si se vio el producto; 0,3 si solo lo dice el ajuste `stack` o no se pudo leer la portada. |
| `no_detectado` | Nada en la portada apunta al producto o la versión afectados. | 0,9 para un plugin de WordPress en un sitio que no es WordPress; 0,8 si la versión está fuera del rango o no se vio el CMS o el framework; 0,6 para un plugin de WordPress que la portada no carga; 0,5 para productos de servidor; 0,2 si el sitio aún no tiene huella. |

`versions` lista lo que se vio (por ejemplo `{"wordpress": "6.6.2", "plugin:woocommerce": "9.3.1"}`), `fingerprinted_at` cuándo, y `fingerprint_via` si la portada se leyó a través del borde (`edge`) o desde tu origen (`origin`). `summary` cuenta los sitios de cada `match`.

Empieza por `affected` y sigue con `posible`. En cada uno, comprueba la versión en el propio servidor y parchea.

## Cómo se juzga cada sitio

La comprobación es pasiva. OpenWAF nunca escanea tus sitios, ni envía cargas de explotación, ni rastrea páginas. Usa dos cosas:

- **El ajuste `stack` del sitio** (`wordpress`, `nextjs`, `generic`, `static`).
- **Una huella de su portada, renovada una vez al día.** El plano de control hace un `GET https://<host>/` como un visitante, a través del borde, con el User-Agent `OpenWAF-Fingerprint/1 (+https://openwaf.dev; …)`. Si el borde responde con un desafío, un bloqueo o un error (por ejemplo en [modo bajo ataque](https://developers.openwaf.dev/es/waf/under-attack/)), hace en su lugar un `GET /` al origen del sitio con la cabecera `Host` del sitio. Nunca se contacta con orígenes en direcciones privadas. No se siguen redirecciones y se leen 2 MiB como mucho. No se consulta `robots.txt`: es tu propio sitio, es una sola petición identificada a la portada al día y no es un rastreo.

De la portada extrae `<meta name="generator">` (versión de WordPress, WooCommerce, Elementor…), la versión del núcleo de WordPress de sus recursos de la biblioteca de bloques y de emojis, los slugs de plugins y temas de `/wp-content/plugins/<slug>/` y `/wp-content/themes/<slug>/` con su `?ver=`, las cabeceras `Server` y `X-Powered-By` (se ignoran los servidores de CDN y de borde), las cabeceras `X-Nextjs-*` y las marcas de Next.js (`/_next/static/`, `__NEXT_DATA__`) y Nuxt (`/_nuxt/`, `__NUXT__`). Next.js, Nuxt y Express implican Node.js.

La vulnerabilidad se compara por producto:

- **Plugins y temas de WordPress** por su slug de wordpress.org, tomado del paquete del registro o de sus referencias de Wordfence, Patchstack, WPScan o wordpress.org.
- **Los demás productos** por nombre o producto CPE: WordPress, Next.js, Nuxt, Express, Node.js, PHP, nginx, Apache HTTP Server, LiteSpeed, OpenResty, IIS, Caddy, Drupal, Joomla y otros.

Los rangos de versiones se comparan cuando se pueden interpretar (rangos de CVE JSON 5, rangos GHSA como `>= 1.0, < 1.2.1`, rangos CPE de NVD).

## Límites

- **`no_detectado` no significa «no afectado».** Significa que la portada no muestra nada que coincida. Una biblioteca de servidor, un backend detrás del sitio o un componente que no deja rastro en el HTML son invisibles para esta comprobación.
- **`?ver=` es una pista.** Los plugins suelen poner ahí su propia versión, pero no siempre; un `?ver=` igual a la versión de WordPress se ignora.
- **Los plugins que solo se cargan en `/wp-admin` son invisibles.** La portada solo muestra los plugins que carga.
- **Un sitio nuevo no tiene huella hasta la siguiente pasada diaria** (`fingerprinted_at: null`, confianza 0,2).

**Consejo:** define el ajuste `stack` del sitio (`stack=wordpress`, `stack=nextjs`). Así, los sitios cuya portada no se puede leer, o que ocultan su tecnología, siguen contando como `posible` para las vulnerabilidades de ese stack. En el panel: **Seguridad → Firewall → Aplicación**; con la CLI:

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

## Mitigaciones del borde

Cuando el borde tiene una protección para una vulnerabilidad, la respuesta la lista en `mitigations` y muestra su estado en cada sitio. Para [CVE-2026-111497 (Node2Shell)](https://developers.openwaf.dev/es/waf/cve-2026-111497/), el borde tiene el [escudo](https://developers.openwaf.dev/es/waf/shields/#brotli-request-body) **1009 «Brotli Request Body»**, que rechaza los cuerpos de petición con `Content-Encoding: br`, y todo backend Node.js se marca como `posible`. El `mitigations[].state` de cada sitio es:

| `state` | Significado |
|---|---|
| `active` | El escudo bloquea en este sitio. |
| `log_only` | El WAF está en modo `log`: el escudo solo registra y las peticiones llegan al origen. |
| `off` | El WAF está en `off`: el escudo no se ejecuta. |
| `exempt_paths` | Una [excepción del WAF](https://developers.openwaf.dev/es/waf/waf-exceptions/) para la regla 1009 lo desactiva en las rutas de `exempt_paths`. |

Una mitigación del borde reduce el riesgo; no parchea tus servidores. Parchéalos como indica el aviso.