→ Back to Home
Application Security

Critical CVSS 10.0 Path Traversal Flaw in GitLab Commits API Prompts Urgent Patching

On September 10, 2026, GitLab issued emergency security releases for GitLab Community Edition (CE) and Enterprise Edition (EE) across versions 19.3.2, 19.2.6, and 19.1.8. The security update resolves a critical vulnerability tracked as CVE-2026-85706, which carries a maximum CVSS v3.1/v4.0 base score of 10.0. The flaw stems from improper path confinement coupled with missing authentication checks within the repository commits API endpoint. In an analysis published on September 11, 2026, security research team watchTowr confirmed successful reproduction of the issue and reported immediate behavioral scanning and reconnaissance probing against global honeypot networks. The vulnerability allows unauthenticated, remote threat actors to execute path traversal attacks against internet-facing and internal GitLab instances, extracting arbitrary files directly from the host filesystem. For organizations relying on self-managed GitLab deployments, the severity cannot be overstated. A successful breach of the central source control system provides attackers with direct visibility into proprietary codebases, application secrets, CI/CD runner tokens, SSH keys, and environmental configurations. Once an attacker extracts these core platform secrets, lateral movement into target cloud infrastructure, container registries, and production workloads becomes trivial. This incident highlights an ongoing, dangerous architectural trend across modern DevOps tooling: the exposure of deeply privileged backend functionality through unauthenticated REST API layers. As enterprises have accelerated developer platform automation, API endpoints designed to parse commit history, diffs, and repository metadata have increasingly become prime targets for path traversal and deserialization exploits. DevSecOps platforms aggregate an enterprise's most critical operational secrets, transforming centralized developer hubs into high-leverage targets that require defensive boundaries as strict as identity providers and production database clusters. In practice, infrastructure and application security teams must immediately identify all self-hosted GitLab CE and EE instances and apply patches to version 19.3.2, 19.2.6, or 19.1.8. If patching cannot be executed immediately, organizations should place self-managed GitLab servers behind strict Identity-Aware Proxies (IAP), VPNs, or Web Application Firewall (WAF) rule sets that block anomalous directory traversal patterns in URI paths. In addition, teams should audit web server access logs for anomalous GET requests targeting the repository commits API endpoint, rotate critical deployment tokens, and assume that any public-facing unpatched instance has likely been surveyed by automated scanning infrastructure.
#gitlab#appsec#vulnerability#cve#devsecops
Read original source