Más de 1.000 servidores GitLab expuestos a ataques RCE: CISA confirma la explotación activa de CVE-2026-97229
Más de 1.000 servidores GitLab siguen expuestos a CVE-2026-97229, una vulnerabilidad RCE crítica con CVSS 10.0 explotada activamente.
Una vulnerabilidad crítica en GitLab Community Edition y Enterprise Edition permite ejecutar código remotamente sin autenticación. Más de 1.000 servidores permanecen expuestos en Internet, pese a que existen actualizaciones de seguridad desde octubre.
La seguridad de las plataformas DevSecOps vuelve a estar en el punto de mira. Más de 1.000 instancias de GitLab accesibles desde Internet continúan siendo vulnerables a una falla crítica que permite ejecutar código arbitrario en los servidores afectados.
La vulnerabilidad, identificada como CVE-2026-97229, tiene una puntuación de CVSS 10.0 (Crítica) y está siendo explotada activamente por actores maliciosos, según la confirmación de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA).
El problema afecta al compilador de expresiones regulares utilizado por el sistema CI/CD de GitLab y podría permitir que un atacante no autenticado consiga ejecución remota de código (RCE) mediante una expresión regular especialmente diseñada.
Aunque GitLab publicó las actualizaciones correctivas el 12 de octubre de 2026, Shadowserver continúa identificando numerosas instalaciones sin actualizar.
CVE-2026-97229: ¿qué sabemos de esta vulnerabilidad crítica de GitLab?
La vulnerabilidad CVE-2026-97229 está relacionada con un desbordamiento de enteros o Integer Overflow, clasificado como CWE-190.
El fallo se encuentra en el compilador de expresiones regulares de CI/CD, encargado de analizar y evaluar las expresiones regulares utilizadas en las configuraciones de los pipelines.
Debido a una validación insuficiente, determinadas expresiones regulares especialmente manipuladas pueden desencadenar condiciones que permitan ejecutar código arbitrario en el servidor GitLab.
Uno de los aspectos más preocupantes es que, bajo determinadas condiciones, el ataque puede realizarse sin necesidad de disponer de una cuenta autenticada.
Ficha técnica de CVE-2026-97229
| Característica | Información |
|---|---|
| Identificador | CVE-2026-97229 |
| Fabricante | GitLab |
| Productos afectados | GitLab CE y EE |
| Severidad | Crítica |
| Puntuación CVSS | 10.0 |
| Vector | Red (AV) |
| Complejidad | Baja (AC) |
| Privilegios requeridos | Ninguno (PR) |
| Interacción del usuario | Ninguna (UI) |
| Tipo de vulnerabilidad | Integer Overflow |
| CWE | CWE-190 |
| Impacto | Ejecución remota de código |
| Estado | Explotación activa confirmada |
La puntuación CVSS 10.0 refleja el elevado impacto potencial sobre la confidencialidad, integridad y disponibilidad de los sistemas afectados.
¿Cómo funciona el ataque contra GitLab?
El origen del problema está en el procesamiento de expresiones regulares dentro de las configuraciones de CI/CD.
GitLab utiliza estas expresiones para evaluar determinadas condiciones y reglas de ejecución de los pipelines. Sin embargo, una validación insuficiente puede provocar un desbordamiento de enteros durante el procesamiento de expresiones especialmente diseñadas.
De forma simplificada, el escenario de ataque puede dividirse en las siguientes fases:
- Identificación del objetivo: el atacante localiza una instancia de GitLab vulnerable y accesible desde Internet.
- Preparación de la entrada maliciosa: construye una expresión regular especialmente manipulada.
- Procesamiento de CI/CD: la expresión llega al compilador de expresiones regulares durante el procesamiento de la configuración del pipeline.
- Explotación del desbordamiento: el error de validación provoca una condición inesperada en el procesamiento interno.
- Ejecución de código: bajo las condiciones necesarias, el atacante puede conseguir ejecutar instrucciones arbitrarias en el servidor.
La ejecución de código en el servidor GitLab podría facilitar el acceso a información confidencial, credenciales, repositorios privados, variables de CI/CD y otros recursos disponibles para la cuenta o proceso comprometido.
Importante: la explotación de esta vulnerabilidad no debe confundirse con una simple denegación de servicio. Su impacto potencial incluye el compromiso completo del servidor.
Más de 1.000 servidores GitLab continúan expuestos
La situación resulta especialmente preocupante por la cantidad de instalaciones que todavía no han aplicado las actualizaciones de seguridad.
El servicio de monitorización de amenazas Shadowserver informó que sigue rastreando más de 1.000 instancias de GitLab vulnerables a CVE-2026-97229 y expuestas a Internet.
Además, Shadowserver identificó más de 11.300 instancias vulnerables a otra vulnerabilidad crítica, CVE-2026-110264, de aproximadamente 39.000 instalaciones de GitLab observadas diariamente.
Estas cifras evidencian un problema recurrente en la administración de infraestructuras: la existencia de sistemas expuestos que permanecen sin actualizar incluso después de la publicación de parches de seguridad.
La inclusión de CVE-2026-97229 en el catálogo Known Exploited Vulnerabilities (KEV) de CISA el 29 de octubre de 2026 confirma que el fallo está siendo explotado en entornos reales.
La agencia estableció el 1 de noviembre de 2026 como fecha límite de remediación para las agencias federales estadounidenses sujetas a la directiva correspondiente.
Versiones de GitLab afectadas
GitLab publicó las correcciones de seguridad el 12 de octubre de 2026 mediante nuevas versiones de mantenimiento.
Las ramas afectadas y sus correspondientes versiones corregidas son:
| Rama vulnerable | Versión corregida |
|---|---|
| GitLab 19.2.x anterior a 19.2.8 | 19.2.8 |
| GitLab 19.3.x anterior a 19.3.5 | 19.3.5 |
| GitLab 19.4.x anterior a 19.4.2 | 19.4.2 |
Las correcciones están disponibles tanto para GitLab Community Edition (CE) como para Enterprise Edition (EE).
GitLab.com ya utiliza una versión corregida, por lo que sus usuarios no necesitan realizar una actualización manual de la plataforma. Los clientes de GitLab Dedicated tampoco necesitan realizar acciones adicionales según el aviso del fabricante.
Las instalaciones autogestionadas deben comprobar su versión y actualizarse inmediatamente.
Cómo comprobar si tu servidor GitLab es vulnerable
Los administradores pueden consultar la versión instalada mediante el siguiente comando:
sudo gitlab-rake gitlab:env:infoTambién pueden utilizar:
sudo gitlab-ctl statusPara obtener información adicional de la instalación:
sudo gitlab-rake gitlab:checkEs importante comparar la versión obtenida con las ramas corregidas publicadas por GitLab.
No basta con comprobar que los servicios están funcionando: una instalación puede estar operativa y continuar siendo vulnerable.
Cómo solucionar CVE-2026-97229: actualización de GitLab
La medida de seguridad prioritaria es instalar una versión corregida.
Los administradores deben actualizar GitLab a una de las siguientes versiones o a una versión posterior compatible:
- GitLab 19.2.8.
- GitLab 19.3.5.
- GitLab 19.4.2.
Antes de realizar el procedimiento, se recomienda generar una copia de seguridad y comprobar la compatibilidad de los componentes instalados.
En instalaciones Omnibus, el procedimiento general incluye:
1. Crear una copia de seguridad
sudo gitlab-backup create2. Comprobar la versión instalada
sudo gitlab-rake gitlab:env:info3. Actualizar GitLab
En sistemas basados en Debian o Ubuntu, se puede utilizar el gestor APT para instalar el paquete correspondiente a la rama corregida:
sudo apt update
sudo apt install gitlab-eePara Community Edition, sustituir el paquete por:
sudo apt install gitlab-ceEn entornos empresariales, debe verificarse previamente que el repositorio configurado ofrece una versión corregida y que la actualización no introduce un cambio de rama incompatible.
4. Reconfigurar y verificar los servicios
sudo gitlab-ctl reconfigure
sudo gitlab-ctl status5. Comprobar nuevamente la versión
sudo gitlab-rake gitlab:env:infoLa actualización debe finalizar con una versión corregida de la rama correspondiente.
Consulta las instrucciones oficiales antes de ejecutar cambios en producción:
Medidas adicionales de protección para GitLab
La actualización es imprescindible, pero no debería ser la única medida de seguridad.
Las organizaciones deben reforzar la protección de sus instancias autogestionadas mediante diferentes controles.
1. Restringir el acceso público
Si GitLab no necesita estar disponible públicamente, debe limitarse el acceso mediante VPN, listas de direcciones IP permitidas o controles de acceso en el firewall.
También conviene revisar los permisos de los proyectos públicos y evitar que usuarios no confiables puedan crear o modificar proyectos que puedan servir como vía de entrada.
2. Revisar las configuraciones de CI/CD
Los administradores deben auditar:
- Archivos
.gitlab-ci.yml. - Expresiones regulares utilizadas en las reglas de pipelines.
- Pipelines ejecutados desde proyectos públicos.
- Cambios recientes en configuraciones de CI/CD.
- Ejecuciones inesperadas de trabajos.
- Modificaciones sospechosas en runners.
Se recomienda revisar especialmente los cambios introducidos por usuarios externos y las configuraciones que procesan entradas no confiables.
3. Proteger las variables y secretos
Las variables CI/CD pueden contener credenciales de acceso a repositorios, servicios cloud, bases de datos y sistemas de producción.
Por ello, es recomendable:
- Utilizar variables protegidas y enmascaradas.
- Evitar almacenar secretos directamente en los repositorios.
- Rotar tokens y credenciales potencialmente expuestos.
- Aplicar el principio de mínimo privilegio.
- Utilizar gestores de secretos externos cuando sea posible.
4. Aislar los runners de GitLab
Los runners no deberían disponer de privilegios innecesarios ni acceso indiscriminado a redes internas.
Se recomienda utilizar ejecutores aislados, contenedores efímeros, restricciones de red y credenciales independientes para cada entorno.
Un runner comprometido puede convertirse en un punto de entrada hacia otros sistemas corporativos.
5. Monitorizar los registros
Es importante centralizar y analizar los registros de GitLab, especialmente los relacionados con:
- Autenticaciones.
- Cambios en proyectos.
- Creación y ejecución de pipelines.
- Modificaciones de variables.
- Actividad de runners.
- Cambios en usuarios y permisos.
Cualquier ejecución de pipeline inesperada o modificación no autorizada debe investigarse.
¿Puede ayudar un WAF como AWS WAF o Cloudflare?
Un firewall de aplicaciones web (WAF) puede aportar una capa adicional de protección, pero es importante entender sus limitaciones.
Un WAF no corrige CVE-2026-97229 ni sustituye la actualización de GitLab.
La vulnerabilidad se encuentra en el procesamiento interno de expresiones regulares. Por tanto, bloquear determinadas peticiones HTTP mediante reglas genéricas no garantiza que se elimine la posibilidad de explotación.
Como medida de defensa en profundidad, pueden implementarse los siguientes controles:
AWS WAF
- Restringir el acceso a las rutas de GitLab que no necesiten exposición pública.
- Aplicar reglas de control de acceso basadas en IP cuando sea viable.
- Utilizar reglas administradas de AWS para detectar patrones de ataques web.
- Habilitar el registro de solicitudes bloqueadas y permitidas.
- Configurar límites de solicitudes para reducir determinados abusos automatizados.
Documentación: https://docs.aws.amazon.com/waf/
Cloudflare WAF
- Restringir el acceso a GitLab mediante reglas personalizadas.
- Aplicar controles de acceso por IP y geolocalización cuando proceda.
- Habilitar reglas administradas y protección frente a tráfico malicioso.
- Revisar los eventos de seguridad y las solicitudes sospechosas.
Documentación: https://developers.cloudflare.com/waf/
Recomendación: si una instalación de GitLab está expuesta a Internet y todavía no puede actualizarse, limitar temporalmente su exposición y restringir el acceso a proyectos públicos puede reducir determinadas vías de ataque demostradas. Sin embargo, estas medidas son compensatorias y no eliminan la vulnerabilidad.
¿Qué hacer si sospechas que tu servidor GitLab ha sido comprometido?
Dado que CISA ha confirmado la explotación activa, las organizaciones que mantengan instalaciones vulnerables deben considerar la posibilidad de que hayan sido atacadas.
En caso de sospecha, se recomienda:
- Aislar temporalmente la instancia afectada de redes no confiables.
- Preservar los registros y evidencias antes de realizar modificaciones.
- Revisar las cuentas de usuario y los accesos administrativos.
- Investigar pipelines y trabajos ejecutados de forma inesperada.
- Analizar los runners y los sistemas conectados.
- Rotar tokens, claves SSH, contraseñas y secretos potencialmente expuestos.
- Comprobar posibles movimientos laterales hacia otros sistemas.
- Actualizar GitLab a una versión corregida.
- Realizar un análisis forense para determinar el alcance del incidente.
Si se confirma una ejecución remota de código, no debe asumirse que actualizar el servidor es suficiente para recuperar su seguridad. También será necesario investigar la posible persistencia del atacante y restaurar la confianza en los sistemas afectados.
Actualizar GitLab debe ser una prioridad
CVE-2026-97229 demuestra que las plataformas DevSecOps también pueden convertirse en objetivos críticos para los atacantes.
La posibilidad de ejecutar código remotamente sin autenticación, unida a una puntuación CVSS de 10.0 y a la confirmación de explotación activa por parte de CISA, convierte esta vulnerabilidad en una amenaza que requiere atención inmediata.
Las organizaciones que utilizan GitLab autogestionado deben verificar sus versiones, aplicar los parches publicados y revisar sus configuraciones de CI/CD, runners y secretos.
En un entorno donde los repositorios contienen código fuente, credenciales y procesos de despliegue, comprometer GitLab puede representar un riesgo mucho mayor que comprometer una simple aplicación web.
No basta con proteger el código: también es imprescindible proteger la plataforma que lo almacena, lo construye y lo despliega.
Fuentes y referencias
- GitLab: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
- CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- CVE Program: https://www.cve.org/CVERecord?id=CVE-2026-97229
- BleepingComputer: https://www.bleepingcomputer.com/news/security/over-1-000-gitlab-servers-vulnerable-to-code-execution-attacks/
- Rapid7: https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/