CVE-2026-85706 is a critical GitLab path-traversal vulnerability that has moved beyond theoretical risk into confirmed exploitation. It affects self-managed GitLab CE/EE and could allow an unauthenticated remote attacker to read arbitrary files from the GitLab.
The vulnerability, affecting all GitLab CE/EE versions from 18.7 through 19.1.7, 19.2 through 19.2.5, and 19.3 through 19.3.1, makes it possible 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.
What makes this vulnerability particularly critical, reflected in its CVSS score of 10.0, is that it can be exploited to steal secrets and configuration detail that may enable further access to the system, compromise CI/CD pipelines, and potentially gain access to other systems GitLab has access to. To make things worse, exploitation requires only that the GitLab instance have at least one public project.
The vulnerability was reported by Mohamed Abdelaiz (S3ntago) and promptly patched by GitLab on September 11. As security firm watchTowr reported, within hours of the disclosure, attackers were conducting in-the-wild probes. Subsequently, CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog.
In addition to patching any public-facing self-hosted GitLab instances, watchTowr recommends that:
Defenders should also hunt through log files for HTTP POST requests to
/api/v4/projects/{id}/repository/commits/URIs containingfile.pathparameters to identify potential exploitation attempts.
Commenting on the disclosure, cybersecurity executive Christopher Houser warned that patching is only part of the story:
Patching stops new reads. It doesn't revoke the deploy tokens, CI variables, and SSH keys an attacker already copied. Rotate those, then check which packages and images your builds pulled while the old credentials were still valid.
Chief information security officer Parker Brisette further highlighted the risks associated with this vulnerability, noting that the requirements for exploitation are minimal:
On a GitLab server the arbitrary files are CI/CD variables, runner tokens, and whatever the logs picked up. watchTowr's Jake Knott put the precondition plainly. One public project has to exist. After that there is no authentication step.
Reddit user GuffariBranderr8 emphasized the importance of adopting additional safety measures:
If sensitive configuration or CI/CD credentials are exposed, an attacker could potentially pivot into other systems, so restricting internet exposure and rotating affected secrets solo be part of the response alongside patching.
To patch affected systems, self-managed GitLab instances should be upgraded to version 19.3.2, 19.2.6, or 19.1.8, as applicable. Two weeks after the initial patch release, GitLab backported the fix to versions 19.0.9 and 18.11.12 of GitLab Community Edition (CE) and Enterprise Edition (EE), despite both version being end-of-life.