Índice de contenidos
Claves de la noticia
- CVE-2026-94083 y CVE-2026-94084 alcanzan una puntuación CVSS de 9,4 y afectan al análisis de tráfico HTTP/2 de Suricata.
- El primer fallo aparece en una transición hacia DNS sobre HTTPS y afecta a una función activada por defecto en Suricata 8.x; el segundo depende de una combinación concreta de reglas.
- Suricata 8.0.7 contiene las correcciones y la rama 7 ya no recibe soporte, por lo que actualizar es la respuesta respaldada por el proyecto.
Dos vulnerabilidades críticas recién catalogadas colocan al propio sensor de red en la superficie de ataque que debe inspeccionar. Los registros CVE publicados este 20 de septiembre describen errores de memoria diferentes en Suricata, ambos corregidos en la versión 8.0.7. No hay en las fuentes primarias consultadas constancia de explotación activa, pero el escenario merece atención porque un IDS o IPS procesa tráfico no confiable y suele operar en un punto privilegiado de la red.
Dos caminos distintos hacia un 9,4
Compartir puntuación no significa compartir exposición. CVE-2026-94083 es una confusión de tipos durante una secuencia HTTP/1, HTTP/2 y DoH2, el protocolo que transporta consultas DNS cifradas dentro de HTTP/2. El registro afecta a la serie 8 desde 8.0.0 hasta cualquier versión anterior a 8.0.7 y precisa que el analizador DoH2 está activado por defecto en la configuración de 8.x.
El commit que corrige el problema muestra la causa con más precisión: durante el cambio de protocolo, Suricata podía sustituir la referencia al protocolo original antes de liberar el estado de HTTP/1. Al limpiar después el flujo, el motor podía tratar esa memoria como si perteneciera a otro tipo. La modificación conserva el protocolo original mientras existe una transición en curso y actualiza la expectativa de la segunda transición.
CVE-2026-94084 se encuentra en otra ruta. Cuando una misma transacción HTTP/2 era inspeccionada por reglas que usaban http.response_header con una transformación y también sin ella, el motor podía liberar y volver a crear los búferes de cabeceras. Comprobaciones posteriores conservaban punteros hacia la asignación anterior, creando un use-after-free. La corrección deja de reemplazar esos vectores y reescribe el almacenamiento existente.
| Registro | Condición relevante | Versiones afectadas |
|---|---|---|
| CVE-2026-94083 | Transición HTTP/1 → HTTP/2 → DoH2; DoH2 predeterminado en 8.x | 8.0.0 hasta antes de 8.0.7 |
| CVE-2026-94084 | Reglas de cabecera HTTP/2 con y sin transformación en la misma transacción | Anteriores a 8.0.7 |
La tabla permite una conclusión operativa: el inventario de CVE-2026-94083 debe empezar por las instalaciones de la rama 8 que conservan DoH2, mientras que CVE-2026-94084 exige revisar además el conjunto real de reglas. La primera condición es general por defecto; la segunda nace de una política de detección concreta. Ninguna de esas diferencias convierte en prudente mantener una versión vulnerable.
El sensor también procesa entrada hostil
Suricata puede actuar como sistema de detección, prevención y monitorización de seguridad. En modo pasivo observa copias del tráfico; en línea puede decidir si un paquete continúa. Ese papel cambia la lectura de un fallo de memoria: un cierre inesperado puede abrir una pérdida de visibilidad y, en ciertos diseños, afectar a la disponibilidad de la red. Un error explotable con mayor alcance tendría además acceso al contexto, registros y metadatos que el sensor necesita para cumplir su función.
El vector CVSS publicado para ambos registros indica acceso por red, baja complejidad, ausencia de privilegios y de interacción del usuario, con alcance sin cambios. No equivale a afirmar que exista un exploit público ni que todos los despliegues puedan atacarse del mismo modo. La distinción es la misma que conviene aplicar al zero-day de Chrome basado en confusión de tipos: la clase de error ayuda a entender el riesgo, pero explotación confirmada, exposición y consecuencias observadas son preguntas independientes.
El parche llegó antes que los nombres públicos
OISF publicó Suricata 8.0.7 el 15 de septiembre como una actualización de seguridad. Los identificadores CVE analizados aquí aparecieron cinco días después y enlazan los commits que ya formaban parte de esa versión. La coordinación permite distribuir código corregido antes de revelar todos los detalles.
El volumen del lanzamiento es excepcional. El aviso oficial lo describe como la versión con más informes de vulnerabilidad recibidos hasta ahora y relaciona el aumento con el análisis asistido por inteligencia artificial. Un recuento de la tabla del propio proyecto ofrece 67 entradas pendientes de identificador público cuando se publicó el boletín. Dos figuraban como críticas según OISF y CVSS, mientras el resto cubría niveles desde bajo hasta alto. No todas representan ejecución de código ni comparten superficie; agruparlas como un único «megafallo» deformaría la prioridad.
Una actualización con comprobaciones medibles
El primer paso es localizar todos los sensores Suricata, incluidos los integrados en dispositivos o imágenes administradas por terceros, y verificar la versión que ejecutan, no solo la que declara el repositorio de paquetes. Después debe comprobarse si DoH2 está habilitado y qué reglas emplean http.response_header con transformaciones. Esos datos ordenan el mantenimiento, pero el destino común debe ser 8.0.7 o una versión posterior que incluya el arreglo.
La actualización debe probarse con las reglas de producción: un sensor puede arrancar y perder cobertura por una incompatibilidad o una recarga fallida. Hay que validar que vuelve a inspeccionar, recibe tráfico y genera las alertas esperadas. Como mostró el parche crítico de N-central, importa medir la versión efectiva, no solo aprobar el cambio.
Suricata 7 ha alcanzado el final de su vida útil. OISF indica que 7.0.17 fue su última versión, de modo que no existe una rama antigua mantenida a la que trasladar estas correcciones. En aparatos que empaquetan Suricata, el operador necesita confirmar con el proveedor qué compilación incorpora 8.0.7; sustituir binarios fuera del mecanismo del fabricante puede romper soporte o futuras actualizaciones. Si el proveedor no ofrece calendario, segmentar el equipo y reducir su exposición es una contención temporal, no un parche.
La prioridad nace de la posición, no solo de la cifra
Estos dos registros son importantes por dónde viven: dentro de un componente diseñado para interpretar protocolos complejos enviados por terceros. CVE-2026-94083 amplía la superficie mediante una función predeterminada; CVE-2026-94084 muestra que incluso las reglas defensivas pueden activar una combinación de memoria insegura. Juntas demuestran que el inventario de seguridad debe incluir los controles que observan la red, no únicamente servidores y puestos.
La conclusión concreta es que dos 9,4 requieren el mismo parche, pero no la misma búsqueda de exposición. Revisar DoH2 localiza rápidamente la condición más extendida; auditar las transformaciones de cabeceras identifica la segunda. Actualizar a 8.0.7 elimina ambas rutas documentadas y evita depender de mitigaciones parciales que pueden reducir detección. Después, una verificación funcional del sensor cierra el ciclo mejor que una simple captura del gestor de paquetes.
