Ing. Calogero Bono
El 12 de octubre de 2026 GitLab publicó las versiones 19.4.2, 19.3.5 y 19.2.8 para Community Edition y Enterprise Edition. Dentro está la corrección de CVE-2026-97229, un fallo con puntuación CVSS 10.0 que puede llevar a la ejecución de código arbitrario en el servidor. El jueves la agencia estadounidense CISA confirmó la explotación activa y lo añadió al catálogo KEV. Si gestionas por tu cuenta una instancia de GitLab, lo importante es actualizar ya.
Algunos términos antes de entrar en los hechos. CVE es el código que identifica una vulnerabilidad pública. CVSS es la puntuación de gravedad de 0 a 10. CI/CD designa las canalizaciones automáticas que compilan, prueban y publican el código. KEV es el catálogo de CISA con los fallos que ya se explotan en ataques reales. RCE significa ejecución remota de código, es decir, lanzar comandos en el servidor de otro.
¿Qué es CVE-2026-97229?
Según la página oficial de GitLab, se trata de un desbordamiento de entero en el compilador de expresiones regulares que se usa en las configuraciones CI/CD. En ciertas condiciones, un usuario no autenticado podía ejecutar código arbitrario en el servidor con una expresión regular construida a propósito, debido a una validación insuficiente.
El vector CVSS es de red, con complejidad baja, sin privilegios y sin interacción del usuario. Por eso la puntuación llega a 10.0. El hallazgo lo reportó joaxcar a través del programa de recompensas por errores de HackerOne.
¿Quién lo está explotando?
Como informa BleepingComputer, CISA añadió el fallo al KEV y pidió a las agencias federales que aseguraran sus servidores antes del domingo. Según The Hacker News, el plazo para las agencias civiles es el 1 de noviembre de 2026.
La inclusión está relacionada con un incidente que dio a conocer Alpine Linux. Un actor desconocido intentó sin éxito explotar el fallo en su instancia los días 20 y 21 de octubre de 2026. Envió configuraciones CI diseñadas a medida y hizo caer los procesos worker ocho veces. En cuatro de esos casos el exploit falló en el paso siguiente. El atacante también descargó la imagen de contenedor de GitLab de Alpine. Los nuevos intentos del 25 y 26 de octubre fueron bloqueados.
Los responsables de mantenimiento de Alpine declararon «The attack came close to working». Añadieron que no encontraron pruebas de que tuviera éxito, pero que no pueden descartarlo, y por eso reconstruyeron la instancia desde cero. Según ellos, el repositorio aports, los paquetes y las versiones publicadas el 21 de octubre no fueron manipulados.
¿Qué versiones están afectadas?
Para CVE-2026-97229, GitLab indica todas las versiones desde la 19.2 anteriores a la 19.2.8, desde la 19.3 anteriores a la 19.3.5 y desde la 19.4 anteriores a la 19.4.2. GitLab.com ya usa la versión corregida. Los inquilinos de GitLab Dedicated se actualizaron con una versión interna antes de la publicación.
GitLab señala también que la 19.3.4 tenía un error en las páginas de merge request con la integración Ona activa. Está resuelto en la 19.3.5. Además, la empresa publicó seis reglas de detección de amenazas para ayudar a quienes gestionan instancias self-managed a identificar intentos de explotación.
Los otros fallos del mismo parche
La versión no contiene solo el caso más grave. Entre las demás correcciones, con las puntuaciones que indica GitLab –
- CVE-2026-92883, cross-site scripting en el resaltado de sintaxis, CVSS 8.7.
- CVE-2026-16301, un usuario con rol Developer podía lanzar canalizaciones en ramas protegidas, CVSS 8.5.
- CVE-2026-14814, envenenamiento de la caché de archivos raw, con posible exposición de variables protegidas, CVSS 8.2.
- CVE-2026-81839, canalizaciones ejecutadas con los privilegios del nuevo grupo tras el traslado de un proyecto (solo EE), CVSS 7.7.
- CVE-2026-96893, inyección en las instrucciones de los agentes de IA de GitLab Duo (solo EE), CVSS 7.3.
Hay además cinco fallos de gravedad media, entre ellos la lectura de notas confidenciales mediante GraphQL y la exposición de tokens en los registros de GitLab Pages. El panorama completo está en la página oficial.
Límites que debes conocer
No sabemos cuántas instancias han sido comprometidas. Shadowserver, citado por BleepingComputer, rastrea casi 2.800 instancias de Community Edition expuestas en Internet, pero no indica cuántas ya están actualizadas. Esa cifra no debe leerse como el número de sistemas vulnerables.
Las fuentes no dicen quién es el atacante ni si hay otros casos además del de Alpine. No se ha publicado el detalle técnico del exploit. GitLab hace públicos los informes 90 días después de publicar el parche, así que podrían llegar más detalles.
Qué cambia para quien trabaja con lo digital
Si tienes un GitLab self-managed para tu estudio o tu empresa, la prioridad es la versión. Un fallo sin autenticación en un servidor que contiene código, secretos y canalizaciones es un riesgo real, también para tus clientes. Quien aloja su repositorio en GitLab.com ya está protegido desde la plataforma.
La lección de Alpine es práctica. Si no puedes descartar un compromiso, reconstruye la instancia y rota los secretos. Automatizar las instalaciones ayuda, como explicamos en la guía sobre Ansible para configuración y despliegue. En los servidores también hace falta disciplina con las actualizaciones, un tema que tratamos en el caso de Fragnesia y PHP2Shell. Otro ejemplo reciente de escaneos tras un parche es Oracle E-Business Suite. Si no tienes tiempo para seguirlo todo, existen alojamientos y servidores gestionados con actualizaciones de seguridad.
Nuestra opinión
El caso muestra lo corto que es el tiempo entre el parche y el ataque. La corrección es del 12 de octubre y los intentos contra Alpine son del 20, es decir, ocho días después. Quien actualiza en el siguiente ciclo mensual llega tarde.
Queda una nota crítica. Se cita a GitLab como presente en más de la mitad de las Fortune 100, y BleepingComputer enumera una serie de fallos de gravedad máxima en el mismo periodo, incluidos otros dos de gravedad máxima. Para un servicio que custodia el código y los secretos de una empresa, esa frecuencia pesa. No basta con decir que GitLab corrige rápido, aunque lo haga. Quien decida mantenerlo todo en casa debe asumir una vigilancia continua, o confiarla a quien se dedica a ello profesionalmente.
Preguntas frecuentes
¿Debo actualizar GitLab de inmediato?
Sí, si la instancia es self-managed y está en las versiones indicadas. GitLab recomienda actualizar de inmediato a 19.4.2, 19.3.5 o 19.2.8. La explotación activa está confirmada por CISA.
¿GitLab.com está en riesgo?
No, según GitLab. GitLab.com ya usa la versión corregida y los inquilinos Dedicated se actualizaron antes de la publicación.
¿Hace falta una cuenta para explotar el fallo?
No. El vector CVSS indica que no se requieren privilegios y que no hay interacción del usuario. El ataque pasa por una configuración CI/CD construida a propósito.
¿Cómo sé si me han atacado?
Las fuentes no ofrecen una forma segura de comprobarlo. GitLab publicó seis reglas de detección para las instancias self-managed. Alpine vio caídas repetidas de los workers tras configuraciones CI anómalas.
¿Basta con actualizar?
Depende. Si la instancia estaba expuesta y sin parchear en los días previos, no puedes descartar un compromiso. Alpine decidió reconstruirla desde cero.
Qué vigilar en las próximas semanas, entre parches y controles
En los próximos días importa saber si aparecen otros casos además de Alpine y si se publican detalles técnicos. Tres consejos.
- Actualiza a la última versión disponible para tu rama y verifica el número de versión después de la instalación.
- Revisa los registros de los workers por caídas repetidas y configuraciones CI inusuales, usando las reglas de detección de GitLab.
- Si la instancia estaba expuesta y sin actualizar, rota los tokens y las variables protegidas y valora la reconstrucción.
