Un RCE de GitLab con CVSS 10 y un DoS en firewalls Cisco entran en la lista de vulnerabilidades explotadas de CISA

Dos nuevas vulnerabilidades entraron esta semana en el catálogo Known Exploited Vulnerabilities (KEV) de CISA, y ambas exigen atención inmediata: un fallo de ejecución remota de código de severidad máxima en GitLab y un defecto de denegación de servicio en la línea Cisco Secure Firewall. Las agencias civiles federales de EE. UU. tienen hasta el 1 de noviembre de 2026 para aplicar las correcciones. Cualquier otra organización debería tomar esa fecha como una referencia razonable.

Qué se ha añadido

• CVE-2026-97229 (CVSS 10.0) – GitLab CE/EE. Un desbordamiento de enteros (wraparound) en la forma en que GitLab valida las expresiones regulares de la configuración CI/CD. Un atacante sin autenticar puede enviar una definición de pipeline manipulada y ejecutar código arbitrario directamente en el servidor GitLab.
• CVE-2026-76418 (CVSS 8.6) – Cisco Secure Firewall ASA y FTD. Un valor de retorno no comprobado provoca una desreferencia de puntero NULL. Un atacante remoto sin autenticar puede forzar el reinicio inesperado del equipo y dejar el firewall fuera de servicio.

Cisco ha reconocido que el fallo del firewall ya se estaba explotando a principios de octubre. No se han hecho públicos detalles sobre quién está detrás de la actividad, cuántas organizaciones fueron atacadas ni qué hicieron los atacantes tras obtener acceso.

El fallo de GitLab ya se ha probado en el mundo real

La entrada de GitLab está vinculada a un incidente en Alpine Linux. Los días 20 y 21 de octubre, un actor no identificado atacó la instancia GitLab autoalojada de la distribución, que todavía no estaba parcheada. El atacante envió configuraciones CI manipuladas que hicieron caer los procesos worker de GitLab ocho veces; en cuatro de esos intentos, la cadena de explotación falló en el paso siguiente. El mismo actor descargó además la imagen de contenedor GitLab del proyecto Alpine. Los intentos posteriores de volver a entrar, el 25 y el 26 de octubre, fueron bloqueados.

Los mantenedores de Alpine concluyeron que el ataque estuvo cerca de funcionar. No encontraron pruebas de un compromiso exitoso, pero tampoco pudieron descartarlo, así que trataron el servidor como comprometido y lo reconstruyeron desde cero. Sus comprobaciones de integridad confirmaron que el repositorio aports, el árbol de paquetes y las versiones publicadas el 21 de octubre no habían sido alterados.

Por qué importa

• GitLab es un punto crítico de la cadena de suministro de software. Un RCE sin autenticación en un servidor GitLab expone de golpe el código fuente, los secretos de CI, las claves de firma y los pipelines de compilación. Incluso un intento fallido, como muestra el caso de Alpine, obliga a una reconstrucción costosa y a una revisión completa de integridad.
• Los firewalls son objetivos de perímetro. Los reinicios repetidos de un equipo ASA/FTD interrumpen la conectividad y el acceso VPN, y pueden servir de distracción o de primer paso para otras actividades.
• Estar en el KEV significa explotación confirmada, no riesgo teórico. Las vulnerabilidades con evidencia de explotación activa deben pasar al principio de la cola de parches.

Qué hacer

1. Actualice GitLab CE/EE a las versiones corregidas publicadas por GitLab. Si no puede parchear de inmediato, limite quién puede enviar configuraciones CI y revise los registros en busca de caídas inusuales de los procesos worker entre el 20 y el 26 de octubre.
2. Actualice Cisco ASA y FTD y vigile los reinicios inesperados de los equipos.
3. Trate el GitLab autoalojado como un activo crítico: sin exposición directa a internet si no es imprescindible, MFA para todos los usuarios, registros de auditoría conservados y rotación de los secretos CI tras cualquier actividad sospechosa.
4. Compruebe su exposición. Inventaríe las instancias GitLab y los firewalls Cisco accesibles desde internet y confirme las versiones instaladas.

Los servidores GitLab y las interfaces de administración de firewalls expuestos hacia el exterior son exactamente el tipo de problema que nuestro servicio de escaneo de vulnerabilidades está diseñado para detectar: versiones sin parchear de productos incluidos en la lista KEV, señaladas antes de que el plazo de corrección empiece a importar.