Overview
A newly disclosed CVSS 10.0 GitLab vulnerability, tracked as CVE-2026-85706, is now being actively exploited in the wild, prompting CISA to add it to its Known Exploited Vulnerabilities (KEV) Catalog. The flaw affects GitLab’s Repository Commits API and allows unauthenticated attackers to read arbitrary files, potentially exposing credentials, secrets, configuration files, and other sensitive information stored on vulnerable GitLab servers.
For organisations that rely on GitLab to manage source code, CI/CD pipelines, and DevSecOps operations, this vulnerability represents a significant risk to both development environments and software supply chains.
Why This Vulnerability Matters
- Unauthenticated access: Attackers do not require valid credentials to exploit the flaw under certain conditions, significantly lowering the barrier to compromise.
- Exposure of sensitive information: Successful exploitation may provide access to credentials, secrets, tokens, configuration files, and other valuable data stored on GitLab servers.
- High-value target: GitLab environments often contain source code, deployment configurations, CI/CD secrets, and cloud credentials that can be leveraged for further attacks.
Understanding CVE-2026-85706
The vulnerability stems from:
- Missing authentication enforcement
- Improper path confinement
- A path traversal weakness within GitLab’s Repository Commits API
In practical terms, attackers can manipulate API requests to read files outside the intended repository location, potentially gaining access to highly sensitive information stored on the server.
GitLab assigned the issue a CVSS score of 10.0, the highest possible severity rating.
Exploitation Started Almost Immediately
Shortly after GitLab released security patches, threat intelligence researchers at watchTowr reported observing active internet-wide probing for vulnerable GitLab instances. According to the researchers, attackers were already attempting to identify and target exposed systems within hours of disclosure.
This rapid weaponisation highlights a growing cybersecurity trend where threat actors move from vulnerability disclosure to active exploitation faster than many organisations can patch.
CISA Adds GitLab Flaw to KEV Catalog
CISA formally added CVE-2026-85706 to its Known Exploited Vulnerabilities Catalog, confirming that the vulnerability is being actively exploited in real-world attacks. Federal agencies were instructed to remediate affected systems under Binding Operational Directive (BOD) 26-04.
While the directive applies specifically to US federal agencies, CISA recommends that all organisations prioritise remediation of KEV-listed vulnerabilities as part of a risk-based vulnerability management programme.
Recommended Actions for Security Teams
- Upgrade affected GitLab instances immediately to patched versions.
- Identify all externally accessible GitLab environments and prioritise remediation based on exposure.
- Review logs for suspicious API activity, especially requests involving:
/api/v4/projects/{id}/repository/commits/and references to:file.pathwhich may indicate exploitation attempts. - Rotate credentials, secrets, and access tokens if there is reason to believe sensitive information may have been exposed.
- Assess CI/CD pipelines and repositories for signs of unauthorised access or tampering.
Affected and Patched Versions
Affected versions include:
- GitLab CE/EE 18.7 through 19.1.7
- GitLab CE/EE 19.2 through 19.2.5
- GitLab CE/EE 19.3 through 19.3.1
Patched releases include:
- 19.1.8
- 19.2.6
- 19.3.2
Expert in the Cloud Insight
GitLab is no longer just a source code repository. For many organisations, it serves as the operational centre of software development, CI/CD automation, cloud deployment, and DevSecOps workflows. A compromise at this layer can expose far more than code, potentially giving attackers access to secrets, credentials, deployment pipelines, and downstream production environments.
The lesson is simple: when a critical vulnerability receives a CVSS 10.0 rating and is added to CISA’s KEV catalogue, patching should be treated as an incident response priority rather than routine maintenance. The organisations that respond fastest are often the ones that avoid becoming the next breach headline.
Leave a Reply