GitLab corrige una falla de CVSS 10 que permite ejecutar código sin autenticación

Si tu empresa aloja su propio GitLab, hoy hay una tarea urgente en la lista. GitLab corrigió CVE-2026-110264, una vulnerabilidad crítica con puntaje CVSS 10,0 que, bajo ciertas condiciones, permitiría a un atacante sin credenciales ejecutar código arbitrario en el servidor.

El aviso fue publicado el 21 de octubre de 2026 y recogido el 22 de octubre por CERT-EU, The Register y BleepingComputer. Hasta ahora ninguna de esas fuentes informa de explotación activa, pero el historial reciente de fallas críticas en plataformas de desarrollo aconseja no esperar.

Qué es CVE-2026-110264

La falla es un desbordamiento de enteros (integer overflow) en el compilador de expresiones regulares de GitLab, el componente que interpreta y valida patrones en configuraciones y otras entradas. Según el proveedor, una expresión regular especialmente construida puede provocar el desbordamiento y, en determinadas circunstancias, derivar en ejecución de código en el servidor sin autenticación previa.

El hallazgo fue reportado por un investigador a través del programa de recompensas de GitLab en HackerOne. La vulnerabilidad afecta tanto a GitLab Community Edition (CE) como a Enterprise Edition (EE).

Versiones afectadas y corregidas

El rango vulnerable es amplio: desde GitLab 7.0 (junio de 2014), es decir, unos doce años de lanzamientos. Según el aviso de CERT-EU, están afectadas las versiones anteriores a:

18.11.13 (desde la 7.0)
19.0.10, 19.1.9, 19.2.9
19.3.6, 19.4.3 y 19.5.1

GitLab.com ya ejecuta la versión corregida y los inquilinos de GitLab Dedicated con las compilaciones indicadas por el proveedor tampoco requieren acción. El riesgo recae en las instalaciones autogestionadas.

Por qué importa tanto

Un servidor GitLab concentra el código fuente, la configuración de CI/CD, tokens de acceso, llaves de despliegue y secretos de infraestructura. Comprometerlo equivale a ganar un punto de apoyo para llegar a producción, a repositorios privados y a la cadena de suministro de software de la organización.

Además, no es la primera alerta máxima reciente: GitLab ya había advertido hace unos diez días de otra falla crítica de ejecución remota (CVE-2026-97229, CVSS 10) en el compilador de expresiones regulares de CI/CD, reportada por el mismo investigador. Dos avisos de gravedad máxima en el mismo componente sugieren que conviene reducir la exposición de la instancia además de parchear.

Qué hacer ahora

Inventariar todas las instancias GitLab autogestionadas, incluidas las de pruebas y las olvidadas.
Actualizar a 19.5.1, 19.4.3, 19.3.6 o al parche retroportado de tu rama (19.2.9, 19.1.9, 19.0.10 o 18.11.13), priorizando las que están expuestas a internet.
Restringir el acceso mediante VPN, listas de IP permitidas o un proxy inverso mientras se completa el parcheo.
Revisar la compromisión: GitLab publicó dos reglas de detección para instancias autogestionadas; úsalas para buscar caídas anómalas de procesos de expresiones regulares y ráfagas de errores de renderizado.
Rotar secretos (tokens, variables de CI/CD, llaves de despliegue) si hay indicios de actividad sospechosa.

El mismo lanzamiento corrige además dos fallas de severidad alta, cinco medias y cuatro bajas, por lo que actualizar aporta beneficios más allá de este CVE.

Lo que todavía no sabemos

No hay confirmación pública de explotación en el mundo real al momento de escribir.
GitLab habla de "ciertas condiciones"; los detalles técnicos completos se publicarán más adelante, por lo que la superficie de ataque real puede precisarse.
Tras el caso de PHP2Shell, la ventana entre parche y exploit funcional se ha acortado; es razonable asumir que habrá intentos pronto.

Referencias oficiales

Conclusión: si administras GitLab propio, actualiza hoy. Un CVSS 10 sin autenticación sobre el sistema que guarda tu código y tus secretos no es una tarea para el próximo sprint.