Guilgo Blog

Notas de mi quehacer diario con las técnologias.

Contexto. La vulnerabilidad CVE-2026-22262 afecta a Suricata (motor de IDS, IPS y NSM): un stack overflow al guardar datasets puede ser explotado por red. Las versiones 8.0.3 y 7.0.14 incluyen el parche de seguridad. Si usas Suricata —solo o integrado con Wazuh u otros— conviene actualizar o aplicar el workaround hasta poder parchear. En entornos donde priorizas parches por CVEs, este debe estar entre los primeros.

Resumen ejecutivo: CVE-2026-22262

CampoValor
CVECVE-2026-22262
Publicación2026/1/27
Severidad NVD9.8 Critical (CVSS)
Severidad OISFHIGH (CVSS 3.1 MODERATE en contexto Suricata)
AfectadosSuricata < 7.0.14 y 8.0.0–8.0.2
Parche7.0.14 y 8.0.3 (13-ene-2026)

Suricata utiliza un buffer en la pila para preparar los datos al guardar un dataset. En versiones anteriores a 7.0.14 y 8.0.3, si el contenido del dataset supera ese tamaño, se produce un desbordamiento de pila. El vector de ataque es red, con impacto alto en disponibilidad y, en valoración NVD, también en confidencialidad e integridad.

Mi punto de vista

Suricata está muy presente en entornos de detección (IDS/IPS) y en pilas que combinan Wazuh, Elastic/OpenSearch o SIEMs propios. Que el fallo esté en la ruta de guardado de datasets implica que no hace falta “romper” el tráfico de inspección: basta con que las reglas que usan dataset con opciones save o state manejen (o reciban) datos suficientemente grandes para disparar el overflow. En la práctica, un atacante que pueda influir en qué se escribe en esos datasets —por ejemplo, mediante tráfico que las reglas correlacionen y almacenen— podría intentar explotarlo.

La diferencia de severidad entre NVD (9.8 Critical) y OISF (HIGH/MODERATE) es esperable: NVD valora de forma genérica “acceso por red” y “impacto alto”, mientras que OISF contextualiza en “Suricata típicamente no está expuesto como servicio de usuario final”. Aun así, en un IDS/IPS que procesa tráfico de red, considerar el riesgo como alto y priorizar parche o workaround me parece sensato, sobre todo en despliegues perimetrales o donde Suricata procesa datos de terceros.

Conclusión práctica: no dejarlo para “cuando toque ciclo de parches”. Si tienes reglas con dataset y opciones save/state, eres candidato al bug; actualizar a 7.0.14 u 8.0.3 (o deshabilitar ese uso) debería estar en la lista corta.

Qué versiones de Suricata están afectadas por CVE-2026-22262

  • Rama 7.0.x: todas las versiones anteriores a 7.0.14.
  • Rama 8.0.x: 8.0.0, 8.0.1 y 8.0.2.
  • Seguras: Suricata 7.0.14 y Suricata 8.0.3 (y superiores en cada rama).

Puedes comprobar tu versión con:

suricata --build-info | head -1
# o
suricata -V

Cómo parchear CVE-2026-22262: actualizar Suricata a 7.0.14 u 8.0.3

Opción 1: Paquetes oficiales (Debian / Ubuntu)

En Debian y Ubuntu, la versión en los repos puede no ser aún 7.0.14/8.0.3. Comprueba la disponible:

apt-cache policy suricata

Si la versión instalada es anterior a 7.0.14 (rama 7) o 8.0.3 (rama 8), actualiza cuando el paquete parcheado llegue a tu distro:

sudo apt-get update
sudo apt-get install --only-upgrade suricata
sudo systemctl restart suricata

En Ubuntu, el PPA estable de OISF suele tener releases pronto:

sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install --only-upgrade suricata
sudo systemctl restart suricata

En Debian, si tu versión estable va retrasada, valora backports (cuando publiquen el paquete parcheado) o compilación desde fuentes.

Opción 2: Compilar desde fuentes (7.0.14 u 8.0.3)

Si tu distro aún no ofrece 7.0.14/8.0.3, puedes instalar desde el tarball oficial. Ejemplo para 8.0.3 (equivalente para 7.0.14 cambiando versión y URL):

# Dependencias típicas (Debian/Ubuntu)
sudo apt-get install -y build-essential libpcap-dev libpcre2-dev libyaml-dev \
  libjansson-dev libnss3-dev libgeoip-dev librust-dev cargo

cd /tmp
wget https://www.openinfosecfoundation.org/download/suricata-8.0.3.tar.gz
wget https://www.openinfosecfoundation.org/download/suricata-8.0.3.tar.gz.sig
gpg --receive-keys 2BA9C98CCDF1E93A
gpg --verify suricata-8.0.3.tar.gz.sig suricata-8.0.3.tar.gz

tar xzf suricata-8.0.3.tar.gz
cd suricata-8.0.3
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
sudo make install
sudo make install-full  # reglas y config por defecto si aplica

Usa los mismos --prefix, --sysconfdir, --localstatedir (y --datadir si lo usaste) que en tu instalación anterior para no romper rutas. Después reinicia el servicio:

sudo systemctl restart suricata

Para 7.0.14, sustituye en las URLs y en el directorio por suricata-7.0.14.

Opción 3: Contenedores / imágenes Docker

Si despliegas Suricata en Docker (o como parte de Wazuh/otro stack), usa una imagen que esté basada en 7.0.14 o 8.0.3 o superior. Revisa el Dockerfile o la imagen oficial/derivada y actualiza el tag o el build cuando incorporen estas versiones.

Workaround si no puedes parchear aún

El propio aviso del CVE y de OISF indica un workaround:

No usar reglas que utilicen datasets con las opciones save ni state.

Pasos prácticos:

  1. Localizar reglas con dataset + save/state
    Busca en tus archivos de reglas (por ejemplo en /etc/suricata/rules o donde tengas cargadas las reglas):

    grep -r "dataset.*save\|dataset.*state" /etc/suricata/
    

    O reglas que definan o usen dataset con esas opciones en la misma línea o en bloques relacionados.

  2. Deshabilitar o comentar esas reglas
    Según cómo esté organizado tu conjunto de reglas (archivos locales, override, etc.), comenta las líneas o desactiva los archivos que contengan uso de dataset con save o state hasta poder actualizar a 7.0.14/8.0.3.

  3. Reiniciar Suricata
    Tras cambiar las reglas:

    sudo systemctl restart suricata
    

Este workaround reduce funcionalidad (pierdes persistencia de datasets en esas reglas), pero elimina la ruta del overflow hasta que apliques el parche.

Validación tras el parche

  • Versión:

    suricata -V
    

    Debe ser ≥ 7.0.14 (rama 7) o ≥ 8.0.3 (rama 8).

  • Arranque y reglas: revisar que Suricata arranque sin errores y que las reglas se carguen (logs del servicio o salida de suricata -c /etc/suricata/suricata.yaml en modo prueba).

  • Si habías aplicado el workaround, puedes volver a habilitar las reglas con dataset + save/state tras confirmar que la versión es parcheada.

Referencias y enlaces (CVE-2026-22262, Suricata)

Si tienes Suricata en el mismo entorno que Wazuh (por ejemplo como motor de detección de red), conviene cruzar las alertas de Wazuh para este CVE con la versión realmente instalada en cada nodo y planificar la ventana de actualización o el workaround en consecuencia. Para otros CVEs en la pila, revisa la guía de parches con Wazuh y WSUS.