GitLab Path Traversal Flaw Enters CISA KEV With Three-Day Patch Deadline

GitLab is urging administrators of self-managed installations to patch a maximum-severity vulnerability that can expose arbitrary files through the repository commits API.

Tracked as CVE-2026-85706, the path traversal flaw affects both GitLab Community Edition and Enterprise Edition. Under certain conditions, an unauthenticated attacker can exploit it remotely with a single HTTP request.

CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on September 11, 2026. US federal agencies must complete remediation by September 14, 2026, leaving an unusually narrow three-day window.

GitLab said it had not confirmed exploitation in the wild. However, security firm watchTowr observed Internet-wide probing for unpatched GitLab servers. KEV inclusion also means defenders should treat the issue as an active threat rather than a theoretical weakness.

Unauthenticated API access can expose server files

CVE-2026-85706 is caused by inadequate path confinement and missing authentication enforcement in repository-commit functionality exposed through the GitLab API. The vulnerability is classified as CWE-22, or improper restriction of a pathname to a limited directory.

An attacker can manipulate file-path handling in the repository commits endpoint so that the GitLab server accesses content outside the intended directory. No valid account or user interaction is required, and the reported attack can be delivered in one request.

Successful exploitation may disclose any files readable by the GitLab service under the specific server configuration. Potential targets include:

• Application and infrastructure configuration files
• Credentials and access tokens
• API keys and other secrets
• Proprietary source code
• Repository data
• Files containing information about connected services

The available technical information establishes arbitrary-file reading. It does not show that CVE-2026-85706 independently permits remote code execution or direct modification of server files.

The vulnerability has a CVSS 3.1 score of 10.0 and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. That rating describes a network-accessible, low-complexity attack requiring neither privileges nor user involvement. The recorded vector assigns high confidentiality and integrity impact, with no availability impact.

Researcher “s3ntago” reported the vulnerability through GitLab’s HackerOne bug-bounty program.

Exact affected versions and safe upgrade targets

The vulnerability affects GitLab CE and EE in three version ranges:

• Versions from 18.7 up to, but not including, 19.1.8
• Versions from 19.2 up to, but not including, 19.2.6
• Versions from 19.3 up to, but not including, 19.3.2

Operators should therefore upgrade to 19.1.8, 19.2.6, or 19.3.2, depending on the release branch deployed.

Some reporting described the correction more generally as applying to the 19.1 line. Administrators should use 19.1.8 as the relevant fixed boundary, rather than assuming that any 19.1 release is safe.

The immediate exposure concerns self-managed installations, particularly servers reachable from the public Internet. GitLab.com was already running a patched version, while GitLab Dedicated customers were told that they did not need to take action.

Organizations should still verify their deployment model instead of relying solely on the GitLab branding attached to an internal service. Self-hosted instances maintained by business units, development teams, subsidiaries, or external providers may fall outside centralized patching processes.

CISA status raises the response priority

CISA placed CVE-2026-85706 in the KEV catalog on September 11, 2026, with a federal remediation deadline of September 14, 2026.

The required response directs agencies to apply vendor mitigations while complying with BOD 26-04, “Prioritizing Security Updates Based on Risk,” and CISA’s forensic triage requirements. Agencies using cloud services must follow the applicable BOD 26-04 provisions or discontinue use when effective mitigations are unavailable. Asset owners must also evaluate Internet exposure and meet the directive’s risk-based patching requirements.

There is a distinction between the public exploitation statements. GitLab had not identified a confirmed compromise, while watchTowr reported scanning and probing rather than verified successful attacks. At the same time, KEV inclusion indicates that CISA considers the vulnerability to meet its criteria for known exploitation.

No threat actor, campaign, victim organization, malicious IP address, payload, user agent, or targeted file path has been publicly identified. The lack of those details limits attribution, but it should not delay remediation.

Internet-wide reconnaissance often precedes exploitation once a vulnerability’s endpoint and request structure become understood. In this case, the absence of authentication and the possibility of a one-request attack reduce the operational cost for attackers.

What defenders should look for

Administrators should inspect GitLab application logs and any reverse-proxy, load-balancer, web application firewall, or API-gateway records positioned in front of the service.

The most relevant pattern is an HTTP POST request targeting a URI shaped like:

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

Requests containing a file.path parameter warrant additional investigation. That combination is a potential sign of exploitation activity, although the available information does not provide enough detail to treat every matching request as conclusively malicious.

No specific payload strings or traversal sequences have been disclosed. Defenders should preserve complete request data where legally and operationally possible, including timestamps, source addresses, headers, parameters, response codes, and response sizes.

If suspicious requests are found, incident responders should determine which files the GitLab service account could read. The investigation should cover configuration directories, repository storage, environment files, integration settings, backups, credentials, tokens, and secrets used to access external systems.

Where evidence supports arbitrary-file access, affected secrets should be treated as exposed and rotated. Teams should also review the downstream services reachable with those credentials. Patching closes the vulnerability but does not invalidate material already obtained by an attacker.

A second critical flaw affects GitLab Enterprise Edition

The same security updates address CVE-2026-87719, a separate insecure-deserialization vulnerability in GitLab Enterprise Edition.

This flaw requires an authenticated user with access to Duo Chat. Under certain conditions, the user can supply a crafted GraphQL subscription argument that bypasses expected serialization handling and triggers server-object lookup.

The resulting access can expose Advanced Search instance configurations and sensitive credentials. Unlike CVE-2026-85706, this vulnerability requires low-level privileges rather than allowing an anonymous attack.

CVE-2026-87719 carries a CVSS 3.1 score of 9.9 and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. It is classified as CWE-502, deserialization of untrusted data.

Affected Enterprise Edition ranges are:

• Versions from 18.3 up to, but not including, 19.1.8
• Versions from 19.2 up to, but not including, 19.2.6
• Versions from 19.3 up to, but not including, 19.3.2

CVE-2026-87719 is not listed in the CISA KEV catalog. Organizations using Duo Chat and Advanced Search should nevertheless include it in their review, particularly when investigating suspicious authenticated activity.

GitLab has faced repeated KEV-listed server-side flaws

The new KEV entry follows other GitLab vulnerabilities that enabled attackers to reach data or internal resources through server-side functionality.

CVE-2023-2825 was another CVSS 10.0 path traversal vulnerability, limited to GitLab CE/EE 16.0.0. It allowed unauthenticated file reading when an attachment was present in a public project nested within at least five groups.

Two older server-side request forgery flaws also entered the KEV catalog in 2026. CVE-2021-39935, affecting the CI Lint API, was added on February 3, 2026, with a federal deadline of February 24, 2026. CVE-2021-22175, involving webhook requests to internal networks, followed on February 18, 2026, with remediation due by March 11, 2026.

For CVE-2026-85706, the response is straightforward: identify every self-managed instance, patch to the fixed release for its branch, examine API traffic, and investigate possible data access. Internet-facing systems should come first.