GitLab CVE-2026-85706: 10.0 sin autenticar, y parchear no alcanza

GitLab publicó el 10 de septiembre una entrega de parches crítica —versiones 19.3.2, 19.2.6 y 19.1.8— que corrige 17 vulnerabilidades. La que se llevó los titulares es CVE-2026-85706, con 10.0 en CVSS 3.1, y la descripción del fabricante explica por qué: "an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API."

Sin autenticarse. Cualquier archivo del servidor. CISA la sumó al catálogo de explotación activa el 11 de septiembre con plazo al 14, que ya venció.

GitLab.com ya está parcheada y los clientes de GitLab Dedicated no tienen que hacer nada. Todo esto es para quien corre su propia instancia.

Por qué el vector dice I:H en una falla que sólo permite leer

Vale detenerse un segundo acá, porque el vector contiene el argumento central de la nota.

Las tres últimas letras dicen C:H/I:H/A:N: impacto alto en confidencialidad, alto en integridad, y ninguno en disponibilidad. Que una falla de sólo lectura tenga impacto alto en integridad parece un error de carga, y no lo es. La explicación está en S:C, scope changed: el daño no se queda en el componente vulnerable.

Leer archivos del servidor de GitLab no modifica GitLab. Pero entre esos archivos está la materia con la que GitLab se conecta a todo lo demás —configuración, claves, tokens de integración, variables de los pipelines—, y con eso sí se modifican otras cosas. La integridad que se pierde no es la del repositorio: es la de los sistemas a los que ese servidor tiene llave.

Por eso actualizar cierra la puerta pero no cancela el problema.

Cuatro de las 17 fallas de la misma entrega exponen credenciales

Este es el dato que convierte la recomendación de rotar en algo más que una precaución genérica. En la misma entrega del 10 de septiembre, GitLab corrigió cuatro vulnerabilidades distintas cuyo resultado es exposición de credenciales o de configuración sensible.

La segunda de la lista merece nombre propio porque también es crítica y quedó tapada. CVE-2026-87719, con 9,9, es una deserialización insegura en GraphQL: según GitLab, permite "an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials". Es CWE-502 y exige estar autenticado, pero el resultado es el mismo destino que la de 10.0.

Las otras dos son CVE-2026-79708, con 8,5, una política de pipeline que expone variables de CI y CD, y CVE-2026-82837, con 5,3, exposición de credenciales en Workhorse.

Cuatro caminos distintos, un solo destino. Cuando el mismo día se corrigen cuatro formas de filtrar secretos en un servidor que estuvo expuesto, la pregunta ya no es si conviene rotarlos.

Qué dice GitLab sobre qué hacer después de actualizar

Acá hay un hueco que vale señalar con precisión, sin convertirlo en acusación.

GitLab hizo bien lo difícil: publicó el parche el 10 de septiembre, describió las 17 fallas con sus rangos de versión y sus puntajes, acreditó a quienes las reportaron, y publicó tres detecciones de amenazas para instancias autoadministradas, orientadas a vigilar intentos de lectura local de archivos. Eso es más de lo que hicieron varios fabricantes de las últimas semanas.

Lo que no hay en esa página es un paso explícito de rotación de secretos. La guía posterior a la actualización remite a las buenas prácticas para asegurar la instancia. Para una falla cuya definición es "un desconocido pudo leer cualquier archivo del servidor", el lector razonable necesita que alguien le diga, con esas palabras, que actualizar no revoca nada.

Tampoco hay una lista pública de qué archivos se leyeron en los ataques observados, así que nadie puede decirte que estás limpio. Lo que sí se puede afirmar es qué clase de material queda al alcance de una lectura arbitraria en un servidor de GitLab: lo que el proceso pueda leer, que en una instalación de GitLab incluye su configuración y el material con el que firma y se conecta a otros servicios.

Por qué el antecedente de GitLab en el catálogo de CISA es el argumento más fuerte

Si alguna instancia autoadministrada se está pensando "lo vemos el mes que viene", el historial del propio producto en el catálogo de explotación activa es el mejor argumento en contra.

En febrero de 2026 CISA agregó al catálogo dos vulnerabilidades de GitLab de 2021: CVE-2021-39935 y CVE-2021-22175. Una falla entra al catálogo cuando hay evidencia de explotación real, así que eso significa que a comienzos de este año todavía se estaban atacando con éxito instancias de GitLab que llevaban casi cinco años sin actualizar.

No es un problema exclusivo de GitLab. Contando en el catálogo las herramientas de desarrollo y de integración continua —GitLab, Jenkins, Atlassian, TeamCity, Artifactory, Nexus, Gitea—, hay 37 entradas, y 10 son de 2026, más que cualquier año anterior. La lógica es la de siempre: un servidor de código concentra el trabajo de toda la empresa y las llaves de sus despliegues, y por eso rinde más que cualquiera de los sistemas que despliega. Es el mismo razonamiento por el que el software autoalojado es un objetivo estable y por el que PaperCut sigue apareciendo.

¿A quién afecta CVE-2026-85706?

A cualquier instancia autoadministrada de GitLab Community Edition o Enterprise Edition en las versiones 18.7 a 19.1.7, 19.2.0 a 19.2.5, o 19.3.0 a 19.3.1.

Queda afuera quien use GitLab.com, que el fabricante ya parchó, y quien tenga GitLab Dedicated, donde GitLab dice que no hay que hacer nada.

En la región el perfil típico no es una empresa de software grande. Es el estudio de desarrollo de diez personas que levantó su GitLab en un VPS hace cuatro años porque salía más barato que las licencias, el proveedor de IT que guarda ahí los scripts de sus clientes, o el área de sistemas que lo instaló para un proyecto y quedó. En los tres casos hay algo en común: nadie tiene asignado el trabajo de actualizarlo, y es exactamente el perfil de las instancias que en febrero seguían cayendo por fallas de 2021.

¿Quién puede ignorar el aviso de GitLab?

Quien no corra GitLab propio. Si tu código está en GitLab.com, en GitHub, en Bitbucket en la nube o en GitLab Dedicated, esta falla no aplica a tu infraestructura.

Con una salvedad que conviene revisar aunque estés en la nube: si alguna vez tuviste una instancia propia y migraste, los tokens y las claves de integración que creaste en esa época pueden seguir siendo válidos. La instancia vieja puede haber quedado prendida en algún lado, y ese es el escenario que más pasa desapercibido.

¿Qué hago si tengo un GitLab propio?

1. Actualizá a 19.1.8, 19.2.6 o 19.3.2, según tu rama. El plazo del catálogo de CISA venció el 14 de septiembre, así que esto ya está tarde en términos de urgencia, no temprano.
2. Antes de actualizar, preservá los registros de la instancia, en particular los accesos a la API de commits. Si hubo lectura de archivos, ahí está lo poco que se puede reconstruir después.
3. Rotá lo que el servidor guardaba, que es el paso que el aviso no explicita. En orden de daño: tokens de acceso personales y de grupo, tokens de runners, claves de despliegue, variables de CI y CD —sobre todo las que dan acceso a la nube o a producción—, credenciales de integraciones, y los secretos de la propia instancia. Es trabajo, y es el trabajo que evita que la lectura de la semana pasada se convierta en el incidente del mes que viene.
4. Revisá los runners y los pipelines por trabajos que no reconozcas y por variables agregadas que nadie recuerde haber puesto. Un token robado se usa desde el pipeline, no desde la interfaz.
5. Activá las detecciones que publicó GitLab. El fabricante liberó tres detecciones de amenazas para instancias autoadministradas orientadas a intentos de lectura local de archivos.
6. Decidí quién actualiza esto de acá en adelante. La lección del historial no es técnica: las instancias que cayeron en febrero por fallas de 2021 no estaban mal configuradas, estaban sin dueño. Si nadie tiene la tarea asignada con nombre, dentro de cuatro años el que lea esta nota vas a ser vos.

Para ordenar la rotación conviene tener dónde guardar lo nuevo sin repetir el problema: el criterio está en gestión de contraseñas, con 1Password y Bitwarden como las opciones del catálogo que sirven para secretos de equipo. El resto del orden de prioridades está en la guía de ciberseguridad para PyMEs de LATAM, los términos en el glosario, y si el GitLab lo administra un tercero, el formato para preguntarle está en cómo responder un cuestionario de seguridad.

Preguntas frecuentes sobre CVE-2026-85706 y GitLab

Actualicé a la versión corregida. ¿Necesito rotar credenciales igual?

Si tu instancia estuvo accesible desde internet en una versión afectada, sí. El parche impide lecturas futuras, pero no invalida nada de lo que pudo salir antes. Como no hay una lista pública de qué archivos se leyeron en los ataques observados, no existe forma de comprobar que no pasó: rotar es lo que convierte esa incertidumbre en un problema cerrado. Si la instancia sólo fue accesible en la red interna, el riesgo baja bastante y podés priorizar la rotación por criticidad en lugar de hacerla toda de golpe.

Mi GitLab sólo es accesible desde la red interna. ¿Estoy cubierto?

Estás mucho mejor, pero no exento. La falla no exige autenticación, así que la puede disparar cualquiera que alcance el servidor por red: un equipo comprometido en la oficina, una VPN de proveedor, o cualquier sistema de la red interna que caiga primero. Reduce la urgencia, no la obligación de actualizar.

¿Qué es CVE-2026-87719 y por qué casi no se habló de ella?

Es la otra falla crítica de la misma entrega, con 9,9, y quedó tapada por el 10.0. Es una deserialización insegura en GraphQL que, según GitLab, permite a un usuario autenticado con acceso a Duo Chat obtener configuración de Advanced Search y credenciales sensibles. Afecta sólo a Enterprise Edition desde la 18.3 y se corrige con las mismas versiones. Como exige cuenta, no entró al catálogo de CISA, pero llega al mismo lugar que la otra.

¿Cómo sé si intentaron explotar esto contra mi instancia?

GitLab publicó tres detecciones de amenazas para instancias autoadministradas orientadas a intentos de lectura local de archivos, y ese es el camino soportado. Por fuera de eso, el lugar donde mirar son los registros de acceso a la API de commits buscando peticiones con recorridos de ruta hacia afuera del repositorio. Tené presente la advertencia de siempre: la ausencia de rastros en un servidor que estuvo expuesto no prueba que no haya pasado nada.

El GitLab lo administra mi proveedor. ¿Qué le pregunto?

Cuatro cosas: en qué versión está la instancia hoy, si ya pasó a 19.1.8, 19.2.6 o 19.3.2, si el servidor estuvo accesible desde internet en las últimas semanas, y qué credenciales rotó después de actualizar. La cuarta es la que distingue a un proveedor que entendió el alcance de esta falla de uno que corrió el instalador.