GitLab autoalojado sufre un fallo de gravedad máxima

Si mantienes un GitLab propio, toca actualizar ya. GitLab publicó el 21 de octubre una tanda de parches de emergencia que corrige, entre otros, un fallo con la nota máxima de gravedad, CVSS 10.0. Permite a alguien sin cuenta ni sesión iniciada ejecutar código arbitrario en el servidor. Según The Hacker News, afecta a todas las versiones desde la 7.0, publicada en 2014.

Y hay un matiz importante: aunque actualizaras hace nueve días, puede que no estés a salvo. Según The Hacker News, la actualización del 12 de octubre solo cubría la versión 19.2 y posteriores. Las nuevas versiones corregidas están un parche por encima de aquella.

Qué ha pasado

El fallo, registrado como CVE-2026-110264, es un desbordamiento de enteros en el compilador de expresiones regulares. GitLab explica en su aviso que, «en determinadas condiciones», un usuario no autenticado podría ejecutar código en el servidor enviando una expresión regular manipulada. La compañía no ha detallado cuáles son esas condiciones.

Afecta a las ediciones Community (CE) y Enterprise (EE). Como el aviso no menciona ningún tipo de despliegue en concreto, según el criterio de GitLab eso significa que todos están afectados: paquetes omnibus, instalación desde código fuente, chart de Helm, etc. Lo descubrió el investigador joaxcar a través del programa de recompensas de GitLab en HackerOne.

GitLab.com ya funciona con la versión corregida. Las instancias de GitLab Dedicated con la 19.3.5-internal0, la 19.4.2-internal0 o posteriores tampoco tienen que hacer nada. El problema es para quien se aloja su propia instancia.

Qué hay que hacer

GitLab recomienda «encarecidamente» actualizar de inmediato a una de estas versiones, según la rama que uses:

• 19.5.1
• 19.4.3
• 19.3.6
• 19.2.9
• 19.1.9
• 19.0.10
• 18.11.13

La corrección se ha llevado también a las ramas 18.11, 19.0, 19.1 y 19.2, además de a las que reciben los parches habituales. Las versiones corregidas solo se han publicado para las ramas de la lista. Quien siga en algo más antiguo tendrá que saltar a una de ellas.

GitLab también ha publicado dos detecciones de amenazas para ayudar a quien tenga instancias autoalojadas a identificar intentos de explotación. El aviso no detalla en qué consisten, así que conviene consultarlas en la documentación de la compañía y revisar los registros del servidor.

No viene solo

El parche corrige doce vulnerabilidades. Además de la crítica, hay dos de gravedad alta:

• CVE-2026-15723 (CVSS 8.2). Afecta a instancias que tengan activada a la vez la vinculación automática de OmniAuth SAML y LDAP. Un usuario autenticado podría hacerse con una cuenta LDAP ajena sin que la víctima hiciera nada.
• CVE-2026-112212 (CVSS 7.5). Un atacante sin cuenta podría envenenar la caché de los documentos de descubrimiento OAuth/OIDC y redirigir ciertos flujos a un servidor bajo su control.

El resto son fallos de gravedad media y baja: fugas de credenciales internas en cabeceras de respuesta, lectura de metadatos de proyectos privados o acceso a funciones de IA de pago sin suscripción, entre otros. GitLab hará públicos los detalles de cada fallo 90 días después del parche.

La otra cara de la forja propia

Montarse la propia forja de código es una buena forma de no depender de una plataforma ajena y de controlar dónde está el código. Pero el control trae responsabilidades: un servidor expuesto a internet con un fallo de este calibre es una puerta abierta a todo lo que guarda, desde el código hasta las credenciales de despliegue. GitLab publica parches programados el segundo y el cuarto miércoles de cada mes, y saca otros de emergencia cuando la gravedad lo exige, como ahora. Estar atento a esos avisos forma parte del trabajo.

Fuentes: GitLab, The Hacker News