CVE-2026-85706 in GitLab
Summary
by MITRE • 09/12/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions, 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
GitLab has addressed a critical security vulnerability impacting its Community Edition (CE) and Enterprise Edition (EE) platforms across multiple release branches, specifically versions prior to 19.1.8 for the 18.x series, before 19.2.6 for the 19.2 series, and before 19.3.2 for the 19.3 series. This flaw stems from a fundamental failure in access control mechanisms within the repository commits API endpoint, allowing unauthenticated actors to bypass intended security boundaries. The core technical deficiency lies in improper path confinement combined with missing authentication enforcement, which collectively create an avenue for unauthorized data exfiltration that compromises the integrity and confidentiality of hosted repositories.
The vulnerability manifests when attackers exploit weaknesses in how the application validates user permissions against specific file paths within a repository's commit history. In a properly secured environment, access to sensitive files or metadata should require valid authentication credentials and appropriate role-based permissions. However, due to the identified flaw, the API endpoint fails to enforce these checks under certain conditions. This allows an unauthenticated user to construct requests that traverse directory boundaries or target specific internal paths without triggering standard authorization gates. The lack of strict path confinement means that input parameters are not sufficiently sanitized or validated against a whitelist of allowed directories, enabling potential traversal attacks similar in nature to CWE-22 Improper Limitation of a Pathname to a Restricted Directory.
From an operational perspective, the impact of this vulnerability is severe for organizations relying on GitLab for source code management and collaboration. An attacker with knowledge of internal file structures or who can enumerate repository contents could read arbitrary files from the server's filesystem if they are exposed through the commits API. This capability effectively grants unauthorized access to sensitive information such as configuration files, private keys, environment variables stored in dotfiles, or proprietary source code that was not intended for public consumption. The ability to retrieve these artifacts without authentication significantly lowers the barrier for entry, turning what might have been a complex exploitation chain into a straightforward data theft operation accessible via simple HTTP requests.
This incident aligns with common attack patterns documented in industry frameworks such as MITRE ATT&CK, particularly those related to Collection and Exfiltration over Alternative Protocols or Unauthorized Access to Resources. The failure represents a classic case of broken access control where the system does not properly verify that the authenticated user is authorized to perform the requested action on the specific resource being accessed. In this context, the absence of authentication enforcement for certain API paths creates an open door for reconnaissance and data harvesting activities by malicious actors scanning public-facing GitLab instances.
To mitigate the risks associated with this vulnerability, administrators must upgrade their GitLab installations immediately to one of the patched versions: 19.1.8 or later for the 18.x branch, 19.2.6 or later for the 19.2 branch, and 19.3.2 or later for the 19.3 branch. Until upgrades are applied, organizations should consider implementing network-level controls such as web application firewalls to restrict access to sensitive API endpoints from untrusted sources. Additionally, reviewing repository visibility settings and ensuring that no critical secrets are stored in accessible locations within commit history can provide a layer of defense against potential exploitation while the infrastructure is being updated. Regular audits of API endpoint configurations and adherence to least-privilege principles for service accounts will further harden the environment against similar access control failures in the future.