GitLab CVE-2026-85706 Added to CISA KEV: Patch Self-Managed Servers Now

By Kiran Sonawane, Senior DevOps & Cloud Engineer
Published: September 12, 2026 | Last Updated: September 18, 2026

GitLab has released critical security updates for CVE-2026-85706 (CVSS 10.0), a path traversal vulnerability affecting self-managed GitLab installations. Under certain conditions, the flaw could allow an unauthenticated remote attacker to read arbitrary files from a vulnerable GitLab server.

Organizations running self-managed GitLab Community Edition (CE) or Enterprise Edition (EE) should upgrade immediately if they are on an affected release. GitLab now states that CVE-2026-85706 has been added to CISA’s Known Exploited Vulnerabilities catalog, which means there is evidence of real-world exploitation rather than only scanning activity.

What Is CVE-2026-85706?

CVE-2026-85706 is a critical path traversal vulnerability affecting GitLab’s repository commits API.

According to GitLab’s official security advisory, the issue is caused by improper path confinement and missing authentication enforcement in the repository commits API.

Under specific conditions, an unauthenticated user could exploit the vulnerability to read arbitrary files from the GitLab server.

Affected GitLab Versions

• GitLab CE and EE versions 18.7 through versions earlier than 19.1.8
• GitLab 19.2 through versions earlier than 19.2.6
• GitLab 19.3 through versions earlier than 19.3.2

The vulnerability has a maximum CVSS score of 10.0 and can be reached remotely without requiring authentication or user interaction under the vulnerable conditions.

CISA KEV Listing Confirms Real-World Exploitation

GitLab has updated its advisory to state that CVE-2026-85706 has been added to CISA’s Known Exploited Vulnerabilities catalog. CISA’s KEV catalog is reserved for vulnerabilities with evidence of active exploitation, making this a stronger signal than the early reports of internet scanning that appeared shortly after disclosure.

This does not mean every vulnerable GitLab server has been compromised. It does mean that administrators of unpatched self-managed instances should treat the issue as an urgent incident-response priority, particularly if the server was internet-accessible while vulnerable.

GitLab states that GitLab.com and GitLab Dedicated are patched. The primary remediation burden is therefore on operators of self-managed deployments.

Why This GitLab Vulnerability Is a Critical Threat

GitLab servers often form a central part of an organization’s software development and CI/CD infrastructure. Sensitive information may therefore be accessible from the underlying GitLab environment depending on how the server is configured.

If CVE-2026-85706 is successfully exploited, exposed server files could potentially contain:

• Source code and internal development information
• CI/CD secrets and deployment credentials
• API keys and access tokens
• GitLab configuration files
• Environment variables
• Application or server logs
• Credentials that could potentially provide access to other systems

The exact information exposed would depend on the files accessible to the GitLab process and the configuration of the affected server.

Organizations operating vulnerable internet-facing installations should treat patching as a high-priority security task. If log analysis or forensic investigation identifies evidence of unauthorized file access, organizations should consider rotating credentials and secrets that may have been exposed.

Another Critical GitLab Vulnerability Was Recently Patched

CVE-2026-85706 is not the only serious GitLab security issue disclosed recently. GitLab previously patched CVE-2026-19478, a critical code injection vulnerability involving GraphQL that affected GitLab Community Edition and Enterprise Edition.

For more details, read our previous coverage of the GitLab CVE-2026-19478 GraphQL vulnerability.

The recurrence of high-severity vulnerabilities highlights why organizations running self-managed GitLab environments should closely monitor vendor security releases and apply critical patches promptly.

GitLab Also Fixes Critical CVE-2026-87719 (CVSS 9.9)

Alongside CVE-2026-85706, GitLab also addressed another critical vulnerability tracked as CVE-2026-87719, which carries a CVSS score of 9.9.

The issue affects GitLab Enterprise Edition and involves insecure deserialization in the GraphQL subscription serializer.

According to GitLab, under certain conditions, an authenticated user with access to Duo Chat could use a specially crafted GraphQL subscription argument to bypass serialization protections and perform server object lookup.

This could potentially expose Advanced Search instance configurations and sensitive credentials.

CVE-2026-87719 Affected Versions

• GitLab EE versions 18.3 through versions earlier than 19.1.8
• GitLab 19.2 through versions earlier than 19.2.6
• GitLab 19.3 through versions earlier than 19.3.2

Additional Security Issues Patched

The same GitLab security release also addresses additional vulnerabilities, including CVE-2026-88765, a high-severity buffer overflow issue affecting GitLab Enterprise Edition.

The vulnerability carries a CVSS score of 8.5.

According to GitLab, under certain conditions, an authenticated attacker could potentially achieve remote code execution by importing a specially crafted Git project export that triggers a buffer overflow during Advanced Search indexing.

The issue was also addressed in GitLab versions 19.1.8, 19.2.6, and 19.3.2.

Mitigation: What GitLab Administrators Should Do

Organizations operating self-managed GitLab installations should first verify their currently installed GitLab version and determine whether it falls within one of the vulnerable version ranges.

Step 1: Apply Official GitLab Security Updates

Affected installations should upgrade to one of the following patched releases or a newer supported version containing the security fixes:

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

GitLab recommends that self-managed installations apply security patch releases promptly.

Step 2: Restrict Network Exposure

If an organization cannot immediately install the security update, administrators should consider restricting unnecessary public access to the GitLab instance until the patch can be safely applied.

Depending on the environment, temporary controls may include firewalls, VPN access, IP allowlisting, reverse-proxy restrictions, or other network-level access controls.

Step 3: Investigate GitLab and Web Server Logs

Security teams should review GitLab application logs, GitLab Workhorse logs, reverse-proxy logs, and web-server logs for suspicious requests involving the repository commits API. GitLab has also published threat detections for CVE-2026-85706, including attempts to read gitlab.yml, abuse the metadata.path parameter, and use suspicious file paths.

One relevant endpoint pattern is:

/api/v4/projects/{id}/repository/commits/

watchTowr has advised defenders to look for suspicious POST requests targeting repository commit endpoints and containing unusual file-related parameters.

Detection of suspicious requests should trigger further investigation. GitLab’s support guidance notes that a request alone does not prove file contents were successfully returned to the attacker. To investigate possible exfiltration, GitLab recommends correlating the request with fields such as Workhorse written_bytes and api_error in api_json.log.

Step 4: Review Potentially Exposed Credentials

If administrators identify evidence suggesting that sensitive files were accessed, they should determine what information may have been exposed.

Depending on the investigation, organizations may need to rotate:

• GitLab access tokens
• CI/CD credentials
• API keys
• Cloud credentials
• Deployment secrets
• Database credentials
• Other secrets stored on or accessible from the affected server

What Administrators Should Prioritize Now

• Patch first: upgrade affected self-managed instances to 19.1.8, 19.2.6, 19.3.2, or a newer supported release that includes the fix.
• Review official detections: look for suspicious file.path or metadata.path activity and other GitLab-published indicators.
• Validate possible exfiltration: correlate API requests with GitLab Workhorse and application logs rather than assuming an HTTP response code proves disclosure.
• Rotate exposed secrets when warranted: if sensitive files such as GitLab configuration or secrets files may have been disclosed, rotate affected credentials and review subsequent activity.

Bottom Line

CVE-2026-85706 is a maximum-severity GitLab vulnerability because, under certain conditions, it could allow an unauthenticated remote attacker to read arbitrary files from a vulnerable self-managed GitLab server.

The risk is particularly serious for internet-facing GitLab installations because GitLab environments can contain sensitive development, configuration, authentication, and CI/CD information.

The threat picture has changed since the vulnerability was first disclosed: GitLab now states that CVE-2026-85706 is in CISA’s Known Exploited Vulnerabilities catalog. That confirms real-world exploitation has occurred, although it does not establish that every observed request resulted in successful file disclosure.

Administrators running affected GitLab installations should upgrade to 19.1.8, 19.2.6, 19.3.2, or a newer supported release containing the fixes and investigate their logs for suspicious activity.

---

Frequently Asked Questions

---

Official Sources

• GitLab Official Security Advisory: GitLab Critical Patch Release
• GitLab Release Notes: Official GitLab Release Notes
• GitLab CVE-2026-19478 Advisory: GitLab Critical Patch Release for CVE-2026-19478
• GitLab Incident Validation Guidance: Validate whether a file was actually exfiltrated via CVE-2026-85706
• watchTowr Threat Intelligence: Early reported probing activity