CVE-2026-42945 — Laboratorio Defensivo NGINX Wazuh SCA

Resumen

Este repositorio documenta un laboratorio defensivo para CVE-2026-42945, que afecta al módulo ngx_http_rewrite_module de NGINX.

El objetivo de este proyecto fue abordar el CVE desde una perspectiva de equipo azul utilizando Wazuh Security Configuration Assessment (SCA) para evaluar de forma centralizada la exposición de NGINX.

El laboratorio verifica dos condiciones de exposición:

1. Una versión sin parche del paquete NGINX en Ubuntu
2. Un patrón de configuración de reescritura de NGINX riesgoso relacionado con CVE-2026-42945

El resultado final es una política SCA centralizada de Wazuh que puede implementarse en servidores NGINX monitoreados a través de la configuración centralizada del agente de Wazuh.

Arquitectura del laboratorio

El laboratorio se construyó utilizando una arquitectura de red segmentada.

Internet / WAN
     |
     |
  pfSense Firewall
     |
     |-----------------------------
     |                             |
    LAN                           DMZ
     |                             |
Wazuh Manager                Ubuntu NGINX Server
Wazuh Dashboard              Wazuh Agent
                             NGINX

Componentes

Objetivo

El objetivo fue construir un flujo de trabajo defensivo seguro y repetible:

Wazuh Manager
     |
     | Política SCA centralizada
     v
Agente Wazuh en servidor NGINX DMZ
     |
     | Verifica versión del paquete y configuración de NGINX
     v
Wazuh Dashboard
     |
     | Muestra verificaciones aprobadas/fallidas
     v
Validación de remediación

Este enfoque permite evaluar la exposición a CVE sin ejecutar código de explotación.

Estrategia de detección

La política SCA personalizada de Wazuh realiza dos verificaciones.

Verificación 1 — Versión del paquete NGINX

La política verifica si la versión del paquete NGINX de Ubuntu instalada coincide con la versión vulnerable observada en el laboratorio.

Versión inicial del paquete vulnerable:

nginx         1.28.3-2ubuntu1
nginx-common  1.28.3-2ubuntu1

Versión del paquete corregida después de la remediación:

nginx         1.28.3-2ubuntu1.1
nginx-common  1.28.3-2ubuntu1.1

Archivo de política:

sca-policy/nginx-cve-2026-42945.yml

Verificación 2 — Configuración de reescritura riesgosa de NGINX

La política también verifica un patrón de reescritura riesgoso relacionado con CVE-2026-42945.

La configuración de prueba riesgosa se almacena aquí:

nginx-config/vulnerable-example.conf

La configuración corregida se almacena aquí:

nginx-config/remediated-example.conf

La condición riesgosa probada en el laboratorio incluye:

directiva rewrite
captura sin nombre como $1
reemplazo que contiene ?
directiva posterior como set

Estructura del repositorio

wazuh-nginx-cve-2026-42945-sca-lab/
├── README.md
├── sca-policy/
│   └── nginx-cve-2026-42945.yml
├── wazuh-config/
│   └── agent.conf
├── nginx-config/
│   ├── vulnerable-example.conf
│   └── remediated-example.conf
├── commands/
│   ├── 01-agent-validation.md
│   ├── 02-nginx-version-check.md
│   ├── 03-sca-policy-deployment.md
│   └── 04-remediation.md
├── screenshots/
│   ├── 01-lab-architecture.png
│   ├── 02-agent-active.png
│   ├── 03-sca-policy-failed.png
│   ├── 04-nginx-package-before.png
│   ├── 05-risky-rewrite-config.png
│   ├── 06-sca-partial-remediation.png
│   ├── 07-nginx-package-after.png
│   └── 08-sca-policy-passed.png
└── docs/
    └── lab-notes.md

Cómo se construyó el laboratorio

Paso 1 — Segmentación de red

El laboratorio utilizó pfSense para separar el entorno en:

LAN:
- Wazuh Manager
- Wazuh Dashboard

DMZ:
- Servidor Ubuntu NGINX
- Agente Wazuh

El servidor Ubuntu NGINX se colocó en la DMZ.
El Wazuh Manager se colocó en la LAN.

Solo se permitió la comunicación Wazuh requerida desde el servidor DMZ al Wazuh Manager.

Paso 2 — Implementación del agente Wazuh

El servidor DMZ Ubuntu se registró como agente de Wazuh.

El agente se verificó desde el Wazuh Manager y se confirmó como activo.

Los comandos de validación están documentados en:

commands/01-agent-validation.md

Estado esperado:

Agent: ubuntu-dmz-nginx2
Status: Active

Paso 3 — Evaluación de la versión de NGINX

Se verificó la versión del paquete NGINX instalado en el servidor DMZ Ubuntu.

Los comandos de verificación de versión están documentados en:

commands/02-nginx-version-check.md

Estado inicial:

nginx         1.28.3-2ubuntu1
nginx-common  1.28.3-2ubuntu1

Después de la actualización del índice de paquetes, la versión candidata corregida estuvo disponible:

1.28.3-2ubuntu1.1

Paso 4 — Configuración riesgosa de NGINX

Se creó una configuración de prueba de NGINX para simular el patrón de reescritura riesgoso.

El ejemplo vulnerable se almacena en:

nginx-config/vulnerable-example.conf

La versión corregida se almacena en:

nginx-config/remediated-example.conf

El propósito no era explotar el servicio, sino validar si Wazuh SCA puede identificar una exposición de configuración local riesgosa.

Paso 5 — Política SCA personalizada de Wazuh

Se creó una política SCA personalizada en el Wazuh Manager.

Archivo de política:

sca-policy/nginx-cve-2026-42945.yml

En el laboratorio, esta política se implementó desde el directorio compartido del Wazuh Manager:

/var/ossec/etc/shared/default/nginx-cve-2026-42945.yml

La política contiene dos verificaciones:

Paso 6 — Configuración centralizada del agente

La política SCA personalizada se implementó utilizando la configuración centralizada del agente de Wazuh.

El archivo de configuración centralizada se almacena en este repositorio como:

wazuh-config/agent.conf

En el laboratorio, se implementó en:

/var/ossec/etc/shared/default/agent.conf

El Wazuh Manager se ejecutaba en Docker:

single-node-wazuh.manager-1

Los comandos de implementación están documentados en:

commands/03-sca-policy-deployment.md

Paso 7 — Validación de la política en el agente

Después de reiniciar el agente de Wazuh, la política SCA personalizada fue recibida por el servidor DMZ Ubuntu.

La política recibida apareció en:

/var/ossec/etc/shared/nginx-cve-2026-42945.yml

Los registros del agente de Wazuh confirmaron que la política se cargó y evaluó.

Indicadores de registro esperados:

Loaded policy
Starting evaluation of policy
Evaluation finished for policy

Resultado inicial

Con ambas condiciones de exposición presentes, el Wazuh Dashboard mostró:

Passed: 0
Failed: 2
Score: 0%

Esto significa que ambas verificaciones fallaron:

Captura de pantalla:

screenshots/03-sca-policy-failed.png

Remediación

Paso de remediación 1 — Corregir la configuración de reescritura riesgosa

La configuración de reescritura riesgosa de NGINX se reemplazó con una configuración más segura.

Archivo de referencia:

nginx-config/remediated-example.conf

Después de corregir la configuración y volver a ejecutar el escaneo SCA de Wazuh, el resultado esperado fue:

Passed: 1
Failed: 1
Score: 50%

En esta etapa:

Captura de pantalla:

screenshots/06-sca-partial-remediation.png

Paso de remediación 2 — Actualizar los paquetes NGINX

Los paquetes NGINX se actualizaron mediante una actualización de paquetes específica.

Los comandos de remediación están documentados en:

commands/04-remediation.md

Antes de la actualización:

Installed: 1.28.3-2ubuntu1
Candidate: 1.28.3-2ubuntu1.1

Después de la actualización:

nginx         1.28.3-2ubuntu1.1
nginx-common  1.28.3-2ubuntu1.1

Captura de pantalla:

screenshots/07-nginx-package-after.png

Resultado final

Después de completar ambos pasos de remediación, el resultado SCA de Wazuh cambió a:

Passed: 2
Failed: 0
Score: 100%

Esto confirmó que:

1. La configuración de reescritura riesgosa fue corregida
2. Los paquetes NGINX se actualizaron a la versión corregida

Captura de pantalla:

screenshots/08-sca-policy-passed.png

Resumen de resultados

Capturas de pantalla

Capturas de pantalla recomendadas:

Consideraciones para producción

Para el laboratorio, la política se implementó a través del grupo default de Wazuh.

En producción, es mejor crear un grupo de agente Wazuh dedicado, por ejemplo:

nginx-servers

Solo los servidores que ejecutan NGINX deben asignarse a ese grupo.

Implementación recomendada para producción:

Wazuh Manager
     |
     | Política SCA centralizada
     v
Grupo de agentes nginx-servers
     |
     | Aplicado solo a sistemas NGINX
     v
Wazuh Dashboard

Esto evita aplicar verificaciones específicas de NGINX a sistemas no relacionados.

Por qué no se usó código de explotación

Este proyecto evita intencionalmente el código de explotación.

El propósito del laboratorio fue demostrar ingeniería de seguridad defensiva, no explotación.

La evaluación se basó en:

exposición de versión de paquete
exposición de configuración
validación SCA centralizada de Wazuh
verificación de remediación

Conclusiones clave

• Wazuh SCA puede utilizarse para evaluar de forma centralizada la exposición a CVE.
• La validación de CVE no siempre requiere ejecutar un exploit.
• La segmentación DMZ con pfSense hace que el laboratorio sea más realista.
• Las políticas SCA personalizadas pueden verificar tanto versiones de paquetes como configuraciones riesgosas.
• La remediación debe validarse con resultados medibles de antes y después.
• Se debe utilizar un grupo de agentes Wazuh dedicado para la implementación en producción.

Aviso legal

Este repositorio es solo para fines educativos y de seguridad defensiva.

No se incluye ningún código de explotación.

Las verificaciones están diseñadas para un entorno de laboratorio controlado y deben revisarse antes de su uso en producción.