El fallo peor calificado de GitLab solo necesita un proyecto público

Un solo proyecto público es el único requisito

La CVE-2026-85706 casi no exige nada a un atacante. El fallo reside en la API de commits de los repositorios de GitLab, donde un confinamiento de rutas defectuoso y la ausencia de una comprobación de autenticación permiten a un usuario no autenticado enviar una solicitud con un parámetro de ruta de archivo y leer archivos arbitrarios del servidor, sin necesidad de iniciar sesión. Jake Knott, de watchTowr, resumió la barrera de entrada en una frase: "La explotación exige un solo requisito, debe existir al menos un proyecto público." La mayoría de las instancias autoalojadas de GitLab tienen al menos una, lo considere o no su propietario expuesta de cara al público.

El fallo tiene una puntuación CVSS de 10.0, el máximo que permite la escala, y afecta a GitLab Community y Enterprise Edition en las versiones 18.7 a 19.1.7, 19.2 a 19.2.5 y 19.3 a 19.3.1. Un servidor expuesto de esta forma no solo filtra código fuente. La API de commits está lo bastante cerca de los archivos de configuración, las definiciones de los pipelines de CI/CD y los tokens de despliegue como para que una lectura exitosa entregue a un atacante las credenciales necesarias para avanzar más dentro de lo que esa instancia de GitLab construye y despliega.

Ya existía un parche antes de que llegara el plazo

Pasó menos de 24 horas entre la publicación del parche y las primeras pruebas detectadas en los honeypots de watchTowr. La propia entrada de la CISA en su catálogo llegó solo unas horas después. Según la valoración de watchTowr, los atacantes ya habían aplicado ingeniería inversa y reproducido la vulnerabilidad a partir del propio parche, el mismo patrón que convierte una divulgación en una carrera en el instante en que se hace pública. El plazo de la CISA solo vincula a las agencias civiles federales de EE. UU., no a una empresa de Múnich o Manchester, pero la cronología de explotación a la que responde no se detiene en esa frontera.

El tercer fallo que Servola rastrea desde agosto

Este no es el primer fallo crítico de GitLab de este verano: es el tercero sondeado activamente en apenas cuatro semanas. Servola cubrió un fallo de GitLab agrupado con problemas críticos en Ray y en software de Apple el 18 de agosto, después un fallo de inyección de código GraphQL en el propio GitLab, la CVE-2026-19478, el 24 de agosto, un error que el propio artículo de TheHackerNews sobre este nuevo fallo vincula explícitamente como el caso anterior de explotación poco después de su divulgación. Tres CVE críticas contra una plataforma ampliamente autoalojada en un mes no es una coincidencia que se pueda achacar a la mala suerte. Es una señal de que la superficie de ataque de GitLab y la velocidad con la que investigadores y atacantes aplican ahora ingeniería inversa a un parche han superado la frecuencia con la que la mayoría de los propietarios autoalojados revisa las actualizaciones.

Ninguno de los tres fallos comparte una causa común. Lo que sí tienen en común es una ventana comprimida: cada uno fue sondeado o explotado a los pocos días de publicarse su parche, no semanas después. Un propietario que revisara las actualizaciones de GitLab con periodicidad mensual habría perdido la ventana segura en los tres casos.

Lo que cambia para una empresa que gestiona GitLab autoalojado

El paso concreto es pequeño: confirme que su instancia está en la 19.1.8, 19.2.6 o 19.3.2 o posterior, y después revise los registros de acceso en busca de solicitudes POST contra el endpoint de commits del repositorio con un parámetro de ruta de archivo, el indicador que watchTowr recomienda buscar. El paso más importante es el que realmente evita que se repita. La NIS2 ya exige a las organizaciones de la UE demostrar que pueden verificar que un parche llegó a cada sistema gestionado, no solo que GitLab publicó uno. Una instancia autoalojada sin nadie asignado a vigilar en tiempo real el catálogo KEV de la CISA o los avisos de seguridad del propio GitLab seguirá descubriendo fallos críticos por una noticia en lugar de por una alerta de monitorización. En España, esto encaja con lo que el INCIBE espera ya de las organizaciones en materia de verificación de parches.

Una empresa que trata cada uno de estos casos como un simulacro de incendio aislado saldrá bien parada esta vez y se perderá la siguiente a la misma velocidad. Una empresa que asigna a alguien la responsabilidad del ritmo de parcheo de GitLab, igual que asigna la de sus reglas de firewall, deja de ser, por tercera vez consecutiva, la última en enterarse.

Leer a continuación: Explotado Semanas Antes de que PaperCut Parcheara  |  Fallo crítico de GitLab golpeó lo autoalojado, no SaaS