Security Intelligence
Loading table of contents...
At a glance:
-
On September 10, GitLab released fixes for CVE-2026-85706 in versions 19.1.8, 19.2.6, and 19.3.2. The vulnerability affects self-managed Community Edition (CE) and Enterprise Edition (EE) deployments.
-
Researchers reported internet-wide probing activity beginning on September 11, 2026, targeting vulnerable GitLab servers and noted that exploitation can occur through a single HTTP request.
-
The vulnerability allows an unauthenticated threat actor to retrieve files outside the intended repository path. Files accessible to the GitLab service account, including credentials, secrets, access tokens, Secure Shell (SSH) keys, and configuration data, may be exposed.
Threat summary
On September 10, 2026, GitLab released security updates for Community Edition (CE) and Enterprise Edition (EE) addressing CVE-2026-85706, a critical vulnerability affecting self-managed GitLab deployments. GitLab assigned the flaw a Common Vulnerability Scoring System (CVSS) score of 10.0 and released fixes in versions 19.1.8, 19.2.6, and 19.3.2.
GitLab is a DevSecOps platform used to host source code repositories, manage software development projects, run Continuous Integration and Continuous Delivery (CI/CD) pipelines, and automate software deployment. GitLab also provides application programming interfaces (APIs) that allow users, integrations, and automation tools to interact with repositories programmatically, including retrieving information about code commits.
The flaw, tracked as CVE-2026-85706, is a path traversal vulnerability affecting an API used to retrieve repository commit information. Path traversal vulnerabilities allow requests to access files outside their intended location.
In this case, GitLab states that an unauthenticated threat actor can manipulate API requests to retrieve files from the underlying GitLab server rather than the requested repository. The vulnerability affects GitLab CE and EE releases from:
-
18.7 before 19.1.8
-
19.2 before 19.2.6
-
19.3 before 19.3.2
Successful exploitation allows access to files readable by the GitLab service account. Depending on how GitLab is deployed, those files may contain application secrets, authentication tokens, Secure Shell (SSH) keys, database credentials, cloud access keys, and configuration data stored on the server. The information exposed depends on the files available to the GitLab service and the permissions assigned to that account.
Researchers reported observing internet-wide probing activity targeting vulnerable GitLab servers beginning on September 11, 2026. Researchers noted that file retrieval can occur through a single HTTP request and recommended reviewing HTTP POST requests to /api/v4/projects/{id}/repository/commits/ containing file.path parameters for evidence of exploitation attempts.
Analysis
GitLab often serves as a central point between source code repositories, build systems, deployment pipelines, cloud platforms, and infrastructure automation tools. As a result, a single GitLab server can contain information that spans multiple environments, including development, staging, and production.
While CVE-2026-85706 is limited to arbitrary file access, the files available to the GitLab service frequently include configuration data, integration settings, access tokens, and credentials used by connected systems. The practical impact therefore depends less on the GitLab server itself and more on what information is stored there and what systems trust that information.
GitLab has previously addressed path traversal vulnerabilities, including CVE-2023-2825. The common theme across these issues is exposure of data stored on the GitLab server.
Understanding what information GitLab stores and which systems depend on that information is therefore an important part of assessing the potential impact of CVE-2026-85706.
Mitigations
- Identify all self-managed GitLab deployments and verify version information across production, development, test, and disaster recovery environments to determine whether affected releases are present and require remediation.
- Upgrade affected systems to GitLab 19.1.8, 19.2.6, 19.3.2, or a later supported release to remove the vulnerable API behavior that allows unauthorized file access.
- Examine HTTP POST requests to /api/v4/projects/{id}/repository/commits/ containing file.path parameters to identify activity consistent with the probing and exploitation attempts reported by researchers.
- Assess credentials, access tokens, SSH keys, application secrets, and deployment credentials stored on affected GitLab systems to identify assets that may require rotation if they were accessible through the vulnerable GitLab service account.
- Restrict unnecessary internet access to self-managed GitLab deployments and validate external exposure through asset inventories or attack surface monitoring to reduce opportunities for remote exploitation and confirm that exposed systems have been upgraded.
Stay on top of emerging threats like this.
Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities.
