CISA metió el 29 de octubre de 2026 dos vulnerabilidades nuevas en su catálogo KEV, el de fallos con evidencia de explotación real. Una es de GitLab y la otra de los cortafuegos de Cisco. Si tienes GitLab montado en tus propias máquinas, esta te toca.
Qué ha pasado
Son dos entradas, publicadas el mismo día en la alerta de CISA:
- CVE-2026-97229, en GitLab Community Edition y Enterprise Edition. Es un desbordamiento de entero: una cuenta interna que se pasa del valor máximo que cabe en la variable y da la vuelta, con lo que el programa sigue operando con un número que no tiene sentido. En titulares ha circulado como fallo de gravedad máxima.
- CVE-2026-76418, en Cisco Secure Firewall ASA y en el software FTD. Aquí el patrón es otro: no se comprueba lo que devuelve una función, se sigue adelante con un puntero nulo y el proceso se va al suelo.
La diferencia entre «está en el KEV» y «tiene un CVSS alto» es toda: el catálogo KEV solo recoge fallos de los que hay pruebas de que alguien los está usando ahí fuera. No es una lista de riesgos teóricos, es una lista de cosas que ya están pasando.
CISA aprovecha el aviso para recordar la directiva BOD 26-04, que obliga a las agencias civiles federales de Estados Unidos a priorizar por riesgo: primero lo que está expuesto a Internet y da control total de la máquina, y lo demás puede esperar. Y añade una pieza que casi nadie comenta: la directiva también fija cuándo hay que comprobar si alguien entró antes de que aplicaras el parche.
Por qué importa
Ese último punto es el que cambia cómo trabajas a partir de hoy.
Un GitLab no es una aplicación más. Dentro hay el código fuente entero, las variables de CI con credenciales de despliegue, los tokens de los runners, las claves de acceso a los registros de contenedores, los webhooks hacia producción. Si alguien ha tenido acceso quince minutos, el parche de esta tarde no le quita nada de lo que ya se llevó. Las credenciales que están en tu GitLab siguen valiendo después de actualizar. Esa es la parte que la gente se salta.
Así que el orden sensato, si administras una instancia propia:
- Saber cuántas tienes. No la que usas a diario: la de aquel proyecto de 2021, la del entorno de pruebas que alguien expuso «un momento» para una demo. Esa es la que te muerde.
- Actualizar, empezando por lo que llega desde Internet.
- Buscar antes de dar por cerrado: usuarios nuevos o con permisos cambiados, tokens de acceso personal creados en las últimas semanas, claves SSH y de despliegue añadidas, runners registrados que no reconoces, webhooks apuntando a sitios raros, jobs de CI modificados en ramas que nadie toca.
- Rotar: tokens de CI, claves de despliegue, secretos de los runners. Todo lo que un visitante hubiera podido leer.
Con el ASA y el FTD la lógica es distinta pero el sitio es peor: está en el perímetro. Un cortafuegos que se reinicia solo no es un incidente de datos, es una caída de la VPN un lunes por la mañana con toda la oficina mirando. Y si tu plan de parcheo del perímetro consiste en «lo miramos en la próxima ventana de mantenimiento», la ventana te la va a poner otro.
Qué no cambia
Seamos justos con la noticia, porque se puede contar más gorda de lo que es.
Que un CVE entre en el KEV no significa que te estén atacando a ti ni que haya una campaña masiva. Significa que hay constancia de explotación en algún sitio. Tampoco son dos fallos del mismo calibre: desreferenciar un puntero nulo suele acabar en caída del servicio, no en ejecución de código, y meterlo en el mismo saco que el de GitLab es confundir dos problemas distintos.
CISA no publica indicadores de compromiso ni detalles de la explotación en estos avisos, así que la caza de rastros te toca montarla con lo que te dé el fabricante. Y BOD 26-04 obliga a las agencias federales estadounidenses, a nadie más: si estás en Valencia, es una recomendación, no una ley. Lo que pasa es que es una recomendación bastante buena.
Una última: entrar en el KEV casi nunca es sinónimo de día cero. En la mayoría de los casos el parche lleva semanas publicado y lo que ha fallado no es el fabricante, es el despliegue.
Nuestra lectura
El KEV se ha convertido, sin pedirlo, en el calendario de parches de medio mundo, y me parece lo mejor que le ha pasado a la gestión de vulnerabilidades en años. Porque es la única lista que separa «esto tiene una puntuación fea» de «esto lo están usando». Cualquiera que haya intentado priorizar un informe con mil hallazgos sabe que la puntuación sola no prioriza nada.
Lo que me parece mal es cómo se consume. La mitad de las organizaciones leen el aviso, actualizan y lo dan por cerrado. Parchear es cortar la entrada; no es echar a quien ya estaba dentro. En un GitLab, donde el botín son credenciales que siguen siendo válidas, esa diferencia lo es todo. Por eso el apartado de BOD 26-04 que obliga a preguntarse «¿me entraron antes?» me parece la parte verdaderamente nueva de la directiva, y la que nadie está comentando.
Y voy con la opinión discutible: un GitLab autoalojado colgando directamente de Internet, sin VPN ni acceso condicionado delante, es una decisión que envejece mal. Si tus runners tienen acceso a producción, tu GitLab es producción, aunque en el inventario figure como «herramienta interna». Tratarlo como un wiki de equipo es el error de base; el CVE de turno solo es la factura.
Esto es lo que nos encontramos cada vez que entramos a gestionar la infraestructura de alguien: el problema casi nunca es que no sepan parchear, es que nadie tiene la lista completa de qué hay expuesto ni desde cuándo. Y una lista que no está, no se parchea.
Cualquier duda me dices y lo vemos. Un saludo, Vicente.