Vulnerabilidad CVSS 10 en GitLab: el significado de «no autenticado» depende de quién pueda crear proyectos en tu servidor

Si administras una instalación propia (self-managed) de GitLab de las ramas 19.2, 19.3 o 19.4, conviene planificar la actualización hoy mismo. El 12 de octubre de 2026, GitLab publicó versiones que corrigen 24 vulnerabilidades. Una de ellas tiene una puntuación CVSS de 10.0: una expresión regular especialmente diseñada en la configuración de CI/CD podría provocar la ejecución de código en el servidor GitLab.

Los titulares afirman que un usuario no autenticado puede ejecutar código en el servidor. El aviso de GitLab es más prudente. Según el aviso, esto es posible «en determinadas condiciones», pero no detalla cuáles. Según The Hack Academy, la vía de explotación que Rapid7 demostró al reproducir el fallo depende, entre otras cosas, de quién pueda crear proyectos y escribir configuraciones de CI/CD en tu servidor.

Qué publica GitLab

Según el aviso de actualización de GitLab, el 12 de octubre de 2026 se publicaron las versiones 19.4.2, 19.3.5 y 19.2.8 de Community Edition y Enterprise Edition. GitLab recomienda encarecidamente actualizar de inmediato todas las instalaciones propias a una de estas versiones. Según el aviso, GitLab.com ya ejecuta una versión corregida y los clientes de GitLab Dedicated no tienen que hacer nada.

La vulnerabilidad principal es CVE-2026-97229. El aviso la describe como un desbordamiento de entero (integer overflow) en el compilador de expresiones regulares de CI/CD. Según el aviso, en determinadas condiciones, la vulnerabilidad podría haber permitido a un usuario no autenticado ejecutar código arbitrario en el servidor GitLab mediante una expresión regular especialmente diseñada en la configuración de CI/CD. El aviso atribuye la vulnerabilidad a una validación insuficiente de las expresiones regulares.

• Versiones afectadas: CE/EE, desde 19.2 hasta antes de 19.2.8, desde 19.3 hasta antes de 19.3.5 y desde 19.4 hasta antes de 19.4.2.
• Gravedad: Critical, CVSS 10.0. Según el vector publicado, la vulnerabilidad se puede explotar a través de la red, la complejidad del ataque es baja y no se requieren privilegios ni interacción del usuario.
• Notificada por: joaxcar, a través del programa de recompensas por errores de GitLab en HackerOne.

Otros detalles del aviso que importan al planificar la actualización:

• 19.3.5, no 19.3.4. Según el aviso, la versión 19.3.4 contenía un error que afectaba a las páginas de merge request cuando la integración con Ona estaba activada. El error se corrigió en 19.3.5.
• El resto de las correcciones. Además de la vulnerabilidad crítica, el aviso enumera cinco vulnerabilidades de gravedad High. Entre ellas hay un XSS en el resaltado de sintaxis (8.7) y una vulnerabilidad que permite a un usuario con el rol Developer ejecutar pipelines en ramas protegidas sin autorización (8.5). Según el aviso, tres vulnerabilidades de gravedad Medium permiten a un usuario no autenticado leer comentarios confidenciales o contenido de work items que no debería poder ver.
• Parches para Ruby. Las listas de correcciones de errores de las tres versiones incluyen parches para expresiones regulares en Ruby 3.3 y 3.4. El aviso no los vincula expresamente con la CVE.
• Los detalles completos, dentro de 90 días. Según la política de GitLab, los issues que describen cada vulnerabilidad se hacen públicos 90 días después de la publicación de la versión que la corrige.
• Interrupción del servicio. Las versiones incluyen migraciones de la base de datos. En una instalación de un solo servidor, la actualización interrumpirá el servicio, porque las migraciones deben terminar antes de que GitLab arranque. En una instalación de varios servidores, se puede actualizar sin interrupción mediante el proceso zero-downtime. La versión 19.3.5 también incluye migraciones que se ejecutan después del despliegue.

El aviso no propone una solución alternativa temporal.

Qué significa «no autenticado» en la práctica

GitLab no explica cuáles son esas condiciones. Según The Hack Academy, Rapid7 publicó su propio análisis el 13 de octubre. Según esa información, los investigadores de Rapid7 reprodujeron la ejecución de código en la imagen oficial de GitLab 19.4.1 Community Edition, pero la misma entrada no provocó la ejecución de código en la imagen oficial de 19.4.2. Según Rapid7, el código se ejecutó en el proceso de Ruby como el usuario git de GitLab.

Según The Hack Academy, la vía de explotación demostrada exigía que el atacante controlara la configuración de CI/CD de un proyecto público, además de otras condiciones relativas al propio proyecto. Rapid7 señaló que, en un servidor con el registro abierto y donde los usuarios nuevos pueden crear proyectos, basta con una cuenta recién creada para cumplir esa condición. En otras palabras, «no autenticado» se refiere aquí a cualquiera que pueda abrir una cuenta en tu servidor. Según esa información, Rapid7 describió una vía de explotación y no afirmó que no hubiera otras.

Para quienes no puedan actualizar de inmediato, Rapid7 propuso restringir el acceso anónimo a los proyectos públicos e impedir que los usuarios que no sean de confianza creen proyectos públicos o escriban en ellos. Según The Hack Academy, Rapid7 subrayó que estas medidas solo reducen la exposición a la vía de explotación que demostró. No corrigen el compilador vulnerable.

Qué imprecisiones hay en la cobertura

El titular de The Hacker News. El artículo se titula «GitLab corrige un fallo CVSS 10.0 que podría permitir a usuarios no autenticados ejecutar código en el servidor». El cuerpo del artículo cita el aviso completo, incluida la salvedad «en determinadas condiciones», pero el titular la omite. Quien lea solo el titular podría concluir que cualquiera que pueda acceder a un servidor GitLab vulnerable puede ejecutar código en él, con independencia de su configuración. El aviso de GitLab no dice eso. Según la reproducción de Rapid7, la vía de explotación demostrada depende de la configuración del servidor.

El número de vulnerabilidades de gravedad High. El artículo de The Hacker News indica que se corrigieron tres vulnerabilidades de gravedad High junto con la vulnerabilidad crítica. En la tabla de GitLab aparecen cinco. Las otras dos afectan solo a Enterprise Edition: CVE-2026-81839 (política de ejecución programada de pipelines, 7.7) y CVE-2026-96893 (inyección de contenido en las instrucciones de un agente de IA en Duo Agent Platform, 7.3). Si utilizas EE, también debes tenerlas en cuenta.

Qué no ha ocurrido

Según The Hack Academy, ninguna de las fuentes consultadas informó de la explotación de CVE-2026-97229 en ataques reales. Rapid7 escribió que, a fecha del 13 de octubre, no había pruebas verificadas de explotación en entornos reales. Cybersecurity Dive informó el 12 de octubre de que no estaba claro si los atacantes habían empezado a explotar la vulnerabilidad y de que, hasta esa mañana, no se había añadido al catálogo KEV de CISA. Estos datos solo son válidos para el momento de su publicación. Según The Hack Academy, Rapid7 reprodujo el fallo en su laboratorio y no publicó el código.

La propia reproducción tiene límites. Demuestra que una vía de explotación funciona, no que sea la única. Mientras no se publiquen los detalles completos, quedan preguntas abiertas. Según The Hack Academy, no se sabe si hay otras vías de explotación, cuál es la causa raíz completa ni qué indicios fiables podrían revelar una explotación. La puntuación CVSS expresa la gravedad de la vulnerabilidad, no el grado de exposición de tu servidor. La exposición real depende de quién pueda crear proyectos en el servidor y de qué usuarios procedan las configuraciones de CI/CD que se procesan en él.

No confundas esta vulnerabilidad con otras anteriores de GitLab. The Hacker News menciona CVE-2026-85706, una vulnerabilidad anterior con una puntuación de 10.0 que, según el artículo, se intentó explotar en entornos reales pocas horas después de su divulgación. Según la cobertura periodística, es otra vulnerabilidad, con una causa y un intervalo de versiones afectados distintos. Lo que ocurrió tras su divulgación no permite sacar conclusiones sobre CVE-2026-97229, pero recuerda el poco tiempo que puede transcurrir entre la divulgación y los intentos de explotación.

Qué implica para tu servidor

Actualiza a la versión correspondiente a tu rama

Actualiza a 19.2.8, 19.3.5 o 19.4.2. En la rama 19.3, actualiza a 19.3.5, no a 19.3.4. Si utilizas un solo servidor, planifica una ventana de interrupción del servicio para las migraciones. Después de actualizar, comprueba que la versión que se está ejecutando sea la corregida.

Revisa quién puede registrarse y crear proyectos

Según la reproducción de Rapid7, la pregunta decisiva es si una persona ajena puede abrir una cuenta y escribir una configuración de CI/CD en un proyecto público. En un servidor de un equipo interno, normalmente no hay motivo para mantener abierto el registro. Comprueba si el registro está abierto, si los usuarios nuevos pueden crear proyectos y quién puede crear proyectos públicos. Conviene restringir estas opciones incluso después de actualizar, porque determinan con qué rapidez cualquier persona en Internet podrá explotar la próxima vulnerabilidad de CI/CD.

Si el registro estaba abierto, revisa qué se ha creado

En un servidor donde el registro estaba abierto mientras se ejecutaba la versión vulnerable, conviene revisar las cuentas y los proyectos públicos creados recientemente, así como sus configuraciones de CI/CD. No se trata de indicadores de explotación publicados: según la información disponible, esos indicadores aún no se conocen. Es un punto de partida razonable para la revisión.

Limita los destinos a los que puede acceder el servidor GitLab

Según Rapid7, el código se ejecutó como el usuario git. Un servidor GitLab necesita tráfico saliente legítimo, por ejemplo, para importar repositorios, enviar webhooks y mantener réplicas de repositorios. Identifica los destinos a los que el servidor realmente necesita conectarse y restringe el acceso a los demás en el cortafuegos. El mismo paquete de correcciones también solucionó una vulnerabilidad SSRF en la importación de repositorios que, según el aviso, permitía acceder a recursos de la red interna. Es otro motivo para separar el servidor GitLab de la red interna tanto como sea posible.

Cómo ayuda nuDefend

nuDefend se ejecuta en tu servidor Linux y aplica dos capas de protección independientes. En la capa de red, el tráfico hacia y desde direcciones IP conocidas como maliciosas se bloquea en el cortafuegos del núcleo. Estas direcciones incluyen servidores de mando y control de botnets, escáneres activos e infraestructura de malware. En la capa de DNS, los dominios peligrosos se neutralizan en todo el sistema, de modo que ninguna aplicación del servidor puede resolverlos ni acceder a ellos. Las listas de amenazas están firmadas criptográficamente y se actualizan de forma automática.

El panel muestra un contador del tráfico saliente bloqueado. Un valor superior a cero puede servir como aviso temprano de que algo en el servidor ha intentado contactar con un servidor externo.

El comando nudefend expose muestra todos los servicios que escuchan en el servidor y quién puede acceder a ellos, desde el punto de vista del propio servidor. Si un servicio que antes solo era interno pasa a ser accesible desde el exterior, nuDefend detecta el cambio y avisa. Puedes bloquear un puerto expuesto desde el panel o la línea de comandos, tras una vista previa que muestra exactamente qué se bloqueará. Si los usuarios de tu servidor GitLab están en un número reducido de países, también puedes usar el bloqueo por países y permitir el acceso solo desde los que elijas. Encontrarás más detalles en la documentación.

En resumen

CVE-2026-97229 tiene una puntuación de 10.0 y GitLab recomienda actualizar de inmediato. Actualiza a 19.2.8, 19.3.5 o 19.4.2. El aviso condiciona la explotación a «determinadas condiciones». Según la reproducción de Rapid7, la vía de explotación demostrada requiere poder controlar la configuración de CI/CD de un proyecto público. Según The Hack Academy, Rapid7 señaló que, en un servidor con el registro abierto y donde los usuarios nuevos pueden crear proyectos, basta con una cuenta recién creada. Después de actualizar, revisa quién puede registrarse y crear proyectos en tu servidor, y restringe los destinos a los que puede acceder el servidor GitLab.