GitLab corrige un fallo 10.0 ya explotado: revisa secretos además de actualizar

25 de septiembre de 2026 a las 02:00|Autor: Equipo editorial de QUASA|6 lectura mínima| 2

El 14 de septiembre de 2026, la explotación de CVE-2026-85706, un fallo de GitLab con una puntuación CVSS de 10,0, ya estaba confirmada. La vulnerabilidad permite que un atacante sin autenticar fuerce la lectura de archivos del servidor mediante la API de commits; la alerta publicada ese día por BleepingComputer recogió tanto los sondeos observados contra sistemas expuestos como su incorporación al catálogo de vulnerabilidades explotadas de CISA.

GitLab había distribuido la corrección el 10 de septiembre para Community Edition y Enterprise Edition. El riesgo se concentra en instalaciones autogestionadas dentro de los rangos afectados: actualizar cierra la vía de ataque, pero no demuestra que el servidor no haya sido examinado ni que ningún fragmento de sus archivos haya llegado a un tercero. Por eso la respuesta debe conservar los registros y evaluar la posible divulgación antes de decidir qué secretos rotar.

Versiones afectadas y destinos de actualización

La nota oficial del parche crítico de GitLab confirma los rangos vulnerables, las versiones corregidas 19.1.8, 19.2.6 y 19.3.2 y la calificación CVSS 10,0. También indica que GitLab.com ya ejecuta código parcheado y que los clientes de GitLab Dedicated no necesitan actuar; la actualización corresponde a las instalaciones Self-Managed afectadas.

Desde 18.7 y antes de 19.1.8: la rama debe avanzar como mínimo hasta 19.1.8.
19.2 y antes de 19.2.6: la versión corregida de esa rama es 19.2.6.
19.3 y antes de 19.3.2: la versión corregida de esa rama es 19.3.2.

Los rangos se aplican tanto a CE como a EE. Como el aviso no restringe el problema a un método de despliegue concreto, deben comprobarse paquetes Linux, instalaciones compiladas desde el código fuente y despliegues mediante Helm. Una versión vulnerable significa que la vía de ataque existía; no equivale, por sí sola, a que la instancia haya sido comprometida.

Qué archivos podía alcanzar una petición anónima

El defecto combina un confinamiento incorrecto de rutas con la falta de autenticación en la API de commits de repositorios. Una petición POST dirigida a /api/v4/projects/:id/repository/commits podía introducir una ruta del servidor en los parámetros file.path o metadata.path, haciendo que GitLab abriera el archivo en lugar del búfer de carga previsto.

Entre las rutas relevantes para la investigación figuran /etc/gitlab/gitlab.rb, /etc/gitlab/gitlab-secrets.json, gitlab.yml, /root/.ssh/id_rsa y /etc/passwd. Sin embargo, que el servidor abra un archivo no implica necesariamente que entregue todo su contenido: la divulgación depende de cómo el analizador procese sus bytes y, cuando se produce, puede limitarse a un fragmento.

Esta diferencia condiciona la respuesta. Una solicitud a una ruta sensible prueba un intento; la correlación de los registros puede demostrar que el archivo fue accesible; solo la evidencia de bytes devueltos permite afirmar que hubo exfiltración de contenido concreto. Por ejemplo, las claves privadas OpenSSH y archivos JSON como gitlab-secrets.json suelen carecer de la secuencia que activa la reflexión del contenido, aunque la aplicación sí pueda haberlos leído.

Cómo localizar intentos sin destruir la evidencia

El procedimiento forense de GitLab Support indica que, antes de reiniciar o actualizar, deben copiarse las variantes de api_json.log, el registro de acceso de GitLab Workhorse y los registros de NGINX; también establece una respuesta de referencia de 54 bytes para una ruta inexistente, que debe validarse en cada entorno por la posible intervención de proxies o compresión. El reinicio puede rotar el registro de Workhorse y eliminar la entrada necesaria para la correlación.

En api_json.log conviene extraer por separado todos los valores de file.path y metadata.path. La ruta del endpoint, el punto del nombre del parámetro y el propio valor pueden llegar codificados; por eso hay que decodificar los porcentajes, resolver segmentos .. y marcar cualquier valor que termine fuera de /uploads/tmp/. No debe descartarse una línea completa porque contenga otra ruta aparentemente legítima.

El correlation_id de cada candidato permite localizar la misma solicitud en Workhorse. Allí, written_bytes registra los bytes enviados al cliente, mientras que api_error puede contener el fragmento reflejado. Estas copias deben protegerse como material sensible porque el propio registro puede terminar almacenando credenciales en texto claro.

El código HTTP aislado no basta para clasificar el resultado. Un api_error con contenido, corroborado por written_bytes, demuestra qué fragmento fue devuelto; una respuesta compatible con una ruta inexistente indica que el archivo no se resolvió. Una lectura que finaliza sin error de decodificación puede devolver una respuesta 401 sin revelar bytes del archivo, pese a que el servidor sí lo abrió.

Cuándo rotar tokens, credenciales y sesiones

La primera prioridad es preservar los registros y desplegar una versión corregida. Después, la rotación puede acotarse a la evidencia: si api_error contiene un fragmento, deben identificarse los secretos visibles en él y revocarse primero aquellos que permiten entrar en GitLab, automatizar tareas o acceder a otros sistemas.

Revocar tokens de acceso, claves de API y credenciales de automatización presentes en los bytes recuperados.
Rotar credenciales expuestas de almacenamiento de objetos, SMTP, LDAP o SSO y revisar la actividad de esos servicios desde el momento de la petición.
Invalidar sesiones o material criptográfico interno si el fragmento permite reutilizarlos o falsificar autenticación.
Solicitar asistencia de GitLab antes de modificar secretos estructurales: no existe una ruta admitida para rotar db_key_base, y una intervención incorrecta puede provocar pérdida de datos.

Si todas las peticiones contra una ruta muestran una firma de no divulgación, la conclusión precisa es que no hay evidencia de contenido devuelto, no que el archivo nunca fuera leído. Si faltan entradas, el colector truncó campos o los registros ya rotaron, la filtración no puede descartarse. En ese escenario, una rotación más amplia es una decisión de contención ante evidencia incompleta, no una prueba de compromiso.

Qué se sabe del incidente

GitLab ha corregido el fallo y existen indicadores para buscar solicitudes maliciosas y distinguir una lectura interna de una divulgación efectiva. La explotación está confirmada, pero no se ha publicado una cifra consolidada de instancias comprometidas. El alcance de cada incidente depende de la versión instalada, el periodo durante el que el servidor estuvo expuesto y la integridad de los registros conservados.