GitLab CVE-2026-85706 Added to CISA KEV

CVE-2026-85706 represents a severe path traversal flaw in GitLab CE and EE, permitting unauthenticated remote actors to retrieve arbitrary files from affected self-managed deployments. Following GitLab’s patch release on September 10, 2026, CISA incorporated the security issue into its KEV catalog the next day. Here is what you need to know about the vulnerability, affected versions, and defender actions.

What Is CVE-2026-85706?

CVE-2026-85706 (CVSS 10.0) is a path traversal flaw in GitLab Community Edition and Enterprise Edition. GitLab says that, under certain conditions, an unauthenticated user could read arbitrary files from the GitLab server because of improper path confinement and missing authentication enforcement in the repository commits API.

The confirmed primary impact is arbitrary file read and information disclosure, though exposed files may contain credentials, tokens, deploy keys, CI/CD configuration, or database secrets that could support follow-on attacks.

The exact impact depends on what the vulnerable server can access and what sensitive data exists on disk. Exposed secrets could allow attackers to access repositories, cloud resources, build runners, package registries, or production deployment workflows. That makes CVE-2026-85706 a serious supply chain and DevOps security issue even though the confirmed behavior is file disclosure rather than direct code execution.

Which GitLab Versions Are Affected?

GitLab confirmed the following affected ranges for self-managed GitLab CE and EE installations:

GitLab says self-managed installations running affected versions should upgrade immediately. GitLab.com was already running a patched version, and GitLab Dedicated customers did not need to take action for this issue.

Internet-facing self-managed instances should receive the highest priority because the flaw requires no authentication. Internal GitLab servers also require remediation if they are reachable from developer networks, build systems, VPN users, or other internal paths an attacker could access after initial compromise.

Is CVE-2026-85706 Being Exploited?

Yes. CISA added CVE-2026-85706 to the KEV catalog based on evidence of active exploitation. The listing sets a September 14, 2026 remediation deadline for federal civilian agencies and provides a strong prioritization signal for other organizations.

watchTowr reported that it reproduced the vulnerability, validated exposure across self-managed GitLab environments, and observed behavioral probes against its honeypot network after the GitLab patch release.

Your security team can prioritize response efforts by continuously monitoring real-time exploit developments, CISA KEV status updates, and actionable threat intelligence related to CVE-2026-85706 using SOCRadar’s Cyber Threat Intelligence. Additionally, you can automatically identify exposed assets and vulnerable infrastructure that needs to be updated right away with Attack Surface Management (ASM).

What Should Defenders Do Now?

Apply the GitLab Fix

Upgrade affected GitLab CE and EE installations to 19.1.8, 19.2.6, or 19.3.2, depending on the deployed branch. Verify the exact running version after the update, not only the planned maintenance record or package inventory.

Inventory every self-managed GitLab instance, including secondary nodes, test systems, disaster-recovery environments, containerized deployments, and systems behind reverse proxies or load balancers.

Reduce Exposure While Remediating

If immediate patching is not possible, restrict access to GitLab from trusted development, administrative, or VPN networks while remediation is completed. This can reduce exposure, but it is not a replacement for upgrading.

Review reverse proxies, load balancers, WAFs, and firewall rules to identify whether self-managed GitLab services were externally reachable during the exploitation window.

Hunt for Suspicious API Activity

Review GitLab, reverse-proxy, WAF, and network logs for suspicious requests to:

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

watchTowr recommends looking for HTTP POST requests to that endpoint containing file.path parameters. Defenders should also review unusual path values, traversal-like strings, repeated unauthenticated requests, unfamiliar source addresses, and unusual response sizes.

The URI pattern is a hunting lead, not a complete detection rule. A clean search does not prove that exploitation did not occur, especially if logs were incomplete, normalized, or not retained.

Assess Possible Secret Exposure

If suspicious file access is found, determine whether exposed files contain CI/CD variables, deploy keys, access tokens, database credentials, cloud secrets, or other sensitive configuration.

Rotate credentials that were confirmed or reasonably suspected to be exposed. Review repository permissions, CI/CD runner activity, recent deployments, package publishing activity, and access from unusual accounts or source addresses.