Introducción
Un equipo de seguridad que monitorea los logs de su instancia GitLab Self-Managed detecta una ráfaga de peticiones HTTP POST contra /api/v4/projects/{id}/repository/commits/ con parámetros file.path que apuntan fuera del directorio del repositorio. No hay token de autenticación en el header. No hay sesión. En una sola petición, un atacante sin credenciales puede extraer el archivo gitlab.rb, los tokens de API de CI/CD o claves SSH almacenadas en el servidor. Ese es el escenario concreto que CVE-2026-85706 habilita, y la CISA acaba de confirmar que ya no es teórico: atacantes están explorando internet activamente buscando instancias sin parche.
La plataforma GitLab —utilizada por más del 50% de las empresas Fortune 100 y con 30 millones de usuarios registrados— quedó expuesta a un vector que combina falta de enforcement de autenticación con una restricción insuficiente de rutas en la API de commits. El impacto no se limita a leer un archivo cualquiera: en arquitecturas DevSecOps modernas, un repositorio GitLab comprometido es una cadena de suministro entera. Los secretos que almacena alimentan pipelines de AWS, credenciales de Kubernetes, tokens de despliegue en Azure y configuraciones de VPN corporativa.
Qué ocurrió
GitLab publicó el parche el jueves en las versiones Community Edition (CE) 19.3.2, Enterprise Edition (EE) 19.2.6 y 19.1, corrigiendo dos defectos concurrentes: la ausencia de validación de autenticación en el endpoint de commits y una delimitación de rutas inadecuada que permite path traversal. El vendor no etiquetó la vulnerabilidad como «activamente explotada» en su advisory inicial, lo cual generó una ventana de exposición de aproximadamente 24 horas.
Esa ventana la aprovechó watchTowr Labs. Su equipo de inteligencia publicó observaciones de probes en internet contra servidores GitLab sin actualizar, especificando que la explotación requiere un único request HTTP. La firma advirtió que, basándose en el historial de vulnerabilidades críticas de GitLab, la transición de «probing» a «explotación indiscriminada» suele ser inmediata. Horas después, CISA incorporó CVE-2026-85706 al catálogo KEV (Known Exploited Vulnerabilities) y activó la Binding Operational Directive BOD 26-04, que otorga a las agencias federales del FCEB un plazo de tres días para aplicar el remediation.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El alcance de este flaw es desproporcionado respecto a la complejidad del exploit. Un atacante no autenticado, con acceso de red al puerto 80/443 de una instancia GitLab, puede leer archivos arbitrarios del filesystem del servidor. En deployments típicos, eso incluye /etc/gitlab/gitlab-secrets.json, que contiene las claves de cifrado de la base de datos, los secretos de GitLab Pages, tokens de OAuth y configuraciones de integración con proveedores cloud.
Para equipos que corren GitLab en AWS EC2 o EKS, la extracción de secretos habilita movimiento lateral hacia buckets S3, instancias RDS, clusters EKS con IAM roles adjuntos, y configuraciones de VPN (OpenVPN, WireGuard) que residen en el mismo host o en subredes internas. Un pipeline de GitLab CI/CD comprometido puede modificar .gitlab-ci.yml para inyectar comandos maliciosos que se ejecuten con privilegios del runner, alcanzando entornos de producción en horas.
Cuantificando: CISA ha marcado cuatro vulnerabilidades de GitLab como activamente explotadas desde noviembre de 2021, incluyendo CVE-2021-22175 y CVE-2021-39935 en febrero de este año. En enero de 2026, GitLab ya había parcheado un bypass de 2FA de alta severidad que permitía a un atacante con el account ID de una víctima eludir la autenticación de dos factores. El patrón es consistente: GitLab acumula CVEs críticos a un ritmo que exige automatización del patching, no ciclos trimestrales.
Detalles técnicos
Componente afectado: Repository Commits API en GitLab CE/EE.
Vectores de ataque combinados:
- Missing Authentication Enforcement: el endpoint /api/v4/projects/{id}/repository/commits/ no valida correctamente la autenticación del solicitante antes de procesar la operación.
- Improper Path Confinement: el parámetro file.path no se restringe al directorio raíz del repositorio, permitiendo secuencias ../ o rutas absolutas que escapan del sandbox.
Indicador de compromiso en logs:
POST /api/v4/projects/{project_id}/repository/commits/ HTTP/1.1
Content-Type: application/json
{
«file_path»: «../../../../etc/gitlab/gitlab-secrets.json»,
«branch»: «main»,
«commit_message»: «x»,
«actions»: [{«action»: «create», «file_path»: «../../../.ssh/id_rsa», «content»: «x»}]
}
Comando para detectar intentos de explotación en logs de Nginx/GitLab:
grep -E «POST /api/v4/projects/[0-9]+/repository/commits/» /var/log/gitlab/nginx/gitlab_access.log \
| grep -E «file.path.*(\.\./|/etc/|/home/|/root/)»
Versiones vulnerables: GitLab CE/EE anteriores a 19.3.2, 19.2.6 y 19.1.
CVSS: Severidad máxima (10.0) según la clasificación de CISA y el vendor.
Requisito del atacante: Ninguno. No autenticado, acceso de red al puerto del servicio.
Qué deberían hacer los administradores y equipos técnicos
Inmediatamente (0-24 horas):
Corto plazo (1-7 días):
Mediano plazo:
Conclusión
CVE-2026-85706 no es un evento aislado sino la confirmación de un patrón: GitLab, por su posición como columna vertebral de la cadena de suministro de software, acumula CVEs que pasan de advisory a explotación activa en menos de 72 horas. La combinación de un vector trivial (un solo request HTTP sin autenticación) con el valor de lo que se puede extraer (secretos de cloud, claves SSH, configuraciones de VPN) convierte cada instancia sin parche en un objetivo de alto retorno para grupos de ransomware y actores estatales.
Para equipos de infraestructura y seguridad, la lección operativa es clara: GitLab Self-Managed no puede mantenerse en un ciclo de actualización trimestral. La automatización del patching, la monitorización de logs con reglas específicas y la rotación preventiva de secretos son requisitos mínimos, no recomendaciones opcionales.
Fuentes
- https://www.bleepingcomputer.com/news/security/cisa-hackers-now-exploit-max-severity-gitlab-flaw-in-attacks/