El 13 de octubre de 2026 GitLab publicó parches para CVE-2026-97229, una vulnerabilidad de severidad máxima (CVSS 10.0) que afecta a Community Edition (CE) y Enterprise Edition (EE). Bajo ciertas condiciones, un usuario sin autenticar podía ejecutar código arbitrario en el servidor de GitLab a través de una expresión regular especialmente diseñada en una configuración de CI/CD.
Resumen
| CVE | CVE-2026-97229 |
| Producto | GitLab CE y EE (self-managed) |
| Componente | Validación de expresiones regulares en configuración de CI/CD |
| Tipo | Desbordamiento de entero / wraparound (CWE-190) |
| Impacto | Ejecución remota de código en el servidor |
| Autenticación | No requiere |
| Puntaje | 10.0 · Crítico (CVSS) |
| Publicación | 13/10/2026 |
| Explotación activa | Sí (agregada al catálogo KEV de CISA el 30/10/2026) |
Versiones afectadas y corregidas
| Rama | Afectadas | Corregida en |
|---|---|---|
| 19.2 | todas antes de 19.2.8 | 19.2.8 |
| 19.3 | todas antes de 19.3.5 | 19.3.5 |
| 19.4 | todas antes de 19.4.2 | 19.4.2 |
GitLab.com (SaaS) y las instancias dedicadas gestionadas por GitLab ya fueron parcheadas. La exposición real es para quienes operan GitLab self-managed.
¿En qué consiste?
GitLab permite controlar cuándo corren los jobs de un pipeline usando reglas que incluyen expresiones regulares (por ejemplo, para disparar un job solo si el nombre de una rama coincide con cierto patrón). Esas reglas forman parte de la configuración de CI/CD y, por diseño, pueden provenir de una fuente no confiable: el contenido de un repositorio.
El problema fue una validación insuficiente de esas expresiones regulares. Al procesar un patrón manipulado, se producía un desbordamiento de entero (integer overflow): un cálculo interno excedía el valor máximo que la variable podía representar y “daba la vuelta” a un valor inesperado. A partir de ese estado corrupto, un atacante podía encadenar la condición hasta lograr ejecución de código en el servidor.
Lo que eleva esto a severidad máxima es la combinación de factores: no requiere autenticación, se dispara por datos que el atacante controla (la configuración de CI/CD) y el resultado es código ejecutándose en el servidor, no solo una caída.
Camino del ataque, a alto nivel
con una expresion regular manipulada"] B --> C["GitLab valida el patron
de forma insuficiente"] C --> D["Desbordamiento de entero
durante el procesamiento"] D --> E["Estado interno corrupto"] E --> F["Ejecucion de codigo arbitrario
en el servidor de GitLab"] class A,B attacker; class C,D,E bug; class F impact;
Explotación en la práctica
No es teórico. Según el aviso de CISA, su incorporación al catálogo KEV se relaciona con un incidente reportado por Alpine Linux: entre el 20 y el 21 de octubre de 2026, un atacante probó una instancia de GitLab sin parchear enviando configuraciones de CI manipuladas, lo que hizo caer los procesos worker ocho veces. En cuatro de esas caídas, el intento falló recién en el paso siguiente. Los mantenedores de la distribución reconstruyeron la instancia desde cero por precaución. Lo cuento con más detalle en CISA agrega a KEV las fallas de GitLab y Cisco.
Otras fallas corregidas en el mismo lote
El parche también resolvió tres vulnerabilidades de severidad alta:
| CVE | Puntaje | Descripción |
|---|---|---|
| CVE-2026-92883 | 8.7 | Cross-site scripting (XSS): un usuario autenticado podía ejecutar JavaScript en la sesión de otros usuarios mediante un repositorio manipulado. |
| CVE-2026-16301 | 8.5 | Autorización indebida: un usuario con rol Developer podía ejecutar pipelines de CI/CD sobre ramas protegidas. |
| CVE-2026-14814 | 8.2 | Expresión regular permisiva que permitía envenenar la caché de archivos raw del repositorio, con potencial exposición de variables de entorno protegidas. |
No es un dato menor que tres de estas cuatro fallas tengan que ver con el manejo de expresiones regulares o de configuraciones de CI/CD: la superficie de ataque de un servidor de CI/CD incluye, por definición, código y configuración que vienen de terceros.
¿Qué hacer?
1. Actualizar ya
Es la solución real y no hay workaround oficial. Actualizá a 19.4.2, 19.3.5 o 19.2.8 según tu rama.
# Ver la version instalada
sudo gitlab-rake gitlab:env:info | grep -i version
# En una instalacion Omnibus (Debian/Ubuntu)
sudo apt update && sudo apt install gitlab-ce # o gitlab-ee
# Verificar el estado luego de actualizar
sudo gitlab-ctl status
2. Priorizar según exposición
- Si tu GitLab es accesible desde Internet, tratalo como una emergencia: hay explotación activa y figura en el KEV de CISA.
- Si es interno, el riesgo baja pero no desaparece (un atacante que ya esté en la red, o un repositorio con contenido malicioso, siguen siendo vectores). Actualizá igual, con ventana de mantenimiento.
3. Revisar si ya te tocó
Dado que la explotación se manifiesta como caídas repetidas de los procesos worker, revisá los logs en busca de reinicios inusuales previos a la actualización.
# Buscar caidas/reinicios de procesos en los logs recientes
sudo gitlab-ctl tail | grep -iE "crash|segfault|restart|worker"
Si encontrás evidencia de explotación, tratá la instancia como comprometida: el estándar de respuesta, igual que hizo Alpine Linux, es reconstruirla desde cero y rotar secretos.
Fuentes
Fuente oficial:
Complementarias:
- NVD (NIST): CVE-2026-97229
- CVE.org: CVE-2026-97229
- CISA: Known Exploited Vulnerabilities Catalog
- The Hacker News: GitLab Patches CVSS 10.0 Flaw
Más sobre buenas prácticas de seguridad en el ciclo de desarrollo en ¿Qué es DevSecOps?.