[2026.09 Vulnerability Report] Analysis of GitLab Unauthenticated Arbitrary File Read Vulnerability (CVE-2026-85706)

CVE-2026-85706 is a critical path traversal vulnerability (CWE-22) found in the widely used DevOps platforms GitLab Community Edition (CE) and Enterprise Edition (EE). Remote attackers can read arbitrary local files accessible to the GitLab server process by sending specially crafted HTTP(S) API requests without requiring authentication.

This vulnerability stems from insufficient file path validation and missing authentication checks within the GitLab Repository Commits API. A successful attack could expose sensitive server-side information—such as system settings, GitLab configuration files, secrets, database credentials, and SSH keys—potentially leading to further system compromise through the use of leaked credentials or encryption keys.

In particular, the exposure of core internal secrets, such as secret\_key\_base, could enable session forgery and privilege escalation, thereby expanding the scope of the impact across the entire GitLab environment. This vulnerability has been assigned the maximum CVSS v3.1 score of 10.0 (Critical); CISA confirmed active exploitation in September 2026 and added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog.

Tags: gitlab, cve-2026-85706

---

1. Overview

CVE-2026-85706 is a severe path traversal (CWE-22) vulnerability discovered in GitLab Community Edition (CE) and Enterprise Edition (EE), widely used DevOps platforms. A remote attacker can send a maliciously crafted HTTP(S) API request without any authentication to read arbitrary local files accessible to the GitLab server process.

This vulnerability arises from insufficient file path validation and missing authentication checks in the GitLab Repository Commits API. A successful attack could expose critical internal server information, such as system configuration files, GitLab configuration files, secrets, database credentials, and SSH keys, and could lead to further system compromises using leaked credentials or encryption keys.

In particular, if core GitLab secrets—such as `secret_key_base`—are exposed, session forgery and privilege escalation become possible, potentially expanding the scope of damage across the entire GitLab environment. This vulnerability was rated 10.0 (Critical)—the highest score under CVSS v3.1—and CISA confirmed its exploitation in September 2026, adding it to the Known Exploited Vulnerabilities (KEV) catalog.

---

2. Cause

This vulnerability arises from a combination of two flaws: the GitLab Repository Commits API references user-supplied paths without validation, and the file-handling logic executes before authentication checks. The interaction of these two flaws allows an unauthenticated remote attacker to read arbitrary files on the server.

2-1. Insufficient File Path Validation

The GitLab Repository Commits API references the `file.path` value provided by the client when processing files to be included in a commit. In the normal processing flow, GitLab Workhorse stores the uploaded file as a temporary file and sets the path to that value.

However, the API does not verify whether the path passed via `file.path` is located within an allowed repository or the temporary file area. Consequently, if an attacker directly specifies an absolute path on the server in the request, GitLab will open and process the file specified by the attacker—located on the server—instead of the intended upload file.

2-2. Issue with Authentication Check Order

In the vulnerable API processing flow, user authentication checks are performed after file processing. In other words, the system first opens and reads the file at the path specified in the request before verifying whether the requester is an authenticated user.

Due to this sequence, even requests without a valid user session or access token pass through the file-reading stage before being blocked by the authentication check. Consequently, an attacker can reach the vulnerable file-processing logic without a separate account or prior permissions.

2-3. Combination of the Two Flaws

Although the two flaws described above do not constitute complete vulnerabilities on their own, when they coexist, they lead to unauthenticated file reading through the following processing flow.

An attacker sends a request containing a manipulated path
GitLab opens and reads the file without validating the path
Although authentication checks are performed after the file is read, the file has already been read
Under certain conditions, part or all of the read file’s contents are returned via the API response

If path validation had been in place, the request would have been blocked in Step 2; if authentication checks had been performed first, it would have been blocked in an earlier step. However, because these two flaws overlap, the request is not filtered out at any point and leads to file exposure.

---

3. Key Attack Process

The attack flow exploiting CVE-2026-85706 proceeds as follows. While this vulnerability itself is limited to read-only access, it can escalate to subsequent attacks through exposed credentials.

Scanning for Target Instances and Accessing Vulnerable APIs:

The attacker scans for GitLab Self-Managed instances exposed to the internet to identify vulnerable versions. They then target public projects that can be read anonymously—without requiring a separate user login or access token—and access the Repository Commits API and Files API (POST /api/v4/projects/{id}/repository/commits, POST/PUT .../repository/files/{file_path}).

Sending Malicious API Requests via File Path Manipulation:

The attacker specifies an arbitrary local file path on the server—rather than a legitimate upload path—in the request’s `file.path` parameter. In the normal processing flow, GitLab Workhorse overwrites this value with a safe temporary file path; however, the attacker bypasses Workhorse’s preprocessing by percent-encoding static segments of the URL path (e.g., representing the “c” in “commits” as %63) and passes the forged `file.path` value directly to the Rails handler. Targeted files may include system configuration files, GitLab configuration files, and secret information.

Loading Internal Server Files and Information Disclosure:

A vulnerable GitLab server reads the local file with GitLab process privileges before performing authentication checks, without verifying whether the provided file path exists within an allowed directory. Subsequently, if a parsing error occurs while the file contents are being processed as request parameters, part or all of the file’s contents may be included in the error response and exposed to the attacker.

Follow-up Attacks and System Compromise Based on Stolen Information:

An attacker can analyze the exposed GitLab configuration information, database credentials, secret keys, or other authentication information to carry out further attacks. In particular, if critical secret information—such as `secret_key_base`—is exposed, this could escalate to session or credential forgery, account takeover, or the acquisition of administrative privileges. Furthermore, there is a possibility that the stolen credentials could be used to exploit features such as CI/CD pipelines or Runners, leading to remote code execution (RCE) and server takeover.

---

4. Impact

CVE-2026-85706 is a critical vulnerability rated 10.0 (Critical) under CVSS v3.1, the highest possible score. Since it allows access to files within the GitLab server without additional authentication, the impact can extend beyond simple information exposure to account compromise, privilege escalation, and compromise of the CI/CD environment.

Leakage of Core Server Confidential Information and Secrets:

Attackers can steal sensitive information—such as system configuration files, GitLab secrets, database credentials, SSH keys, deployment tokens, and CI/CD variables—that are accessible with GitLab server process privileges. In particular, if the /etc/gitlab/gitlab-secrets.json file—which is specifically targeted by the publicly available exploit code—is exposed, the encryption keys contained in this file could be used to decrypt other secrets stored by GitLab, potentially leading to a cascading increase in damage.

Potential for Follow-up Attacks and System Compromise:

Leaked secret keys, authentication information, or database credentials serve as the foundation for additional attacks, such as account takeover, session spoofing, and access to internal services. As a result, the scope of the breach may extend beyond the exposure of a single file to encompass the entire GitLab server and its associated internal infrastructure. It is important to note that while the patch blocks future file reads, it does not invalidate secrets that have already been leaked; therefore, the risk persists until potentially exposed credentials are revoked and reissued.

Compromise of CI/CD Supply Chain Integrity:

Since GitLab is used as a core platform for source code management and build and deployment automation, if an attacker gains control of a repository or CI/CD pipeline, the attack can escalate into a software supply chain attack, including source code tampering, modification of deployment scripts, credential theft, and tampering with build artifacts.

Confirmed Exploitation (CISA KEV Listing):

On September 11, 2026, CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities (KEV) catalog and required federal agencies to complete remedial actions by September 14. Security firm watchTower reported observing scans across the internet beginning at 06:00 (UTC) on September 11 and subsequently confirmed that activity had progressed beyond simple detection to actual exploitation and the exfiltration of sensitive files. According to data compiled by the ShadowServer Foundation, as of the time of this report, thousands of exposed servers remain vulnerable, and vulnerable versions of GitLab Self-Managed environments exposed to the internet face a widespread risk of exploitation.

---

5. Mitigation Measures

Since CVE-2026-85706 is a Critical-rated vulnerability currently being exploited in real-world attacks, organizations operating GitLab Self-Managed environments must prioritize applying the official security patch.

5-1. Security Patches and Version Updates

Upgrade immediately to the official security update version provided by GitLab. The fix versions for each affected version are as follows.

GitLab 19.3.x users: Update to 19.3.2 or later
GitLab 19.2.x users: Update to version 19.2.6 or later
GitLab 18.7–19.1.x users: Update to version 19.1.8 or later

* This patch release also includes a CVSS 9.9-rated GitLab EE deserialization vulnerability (CVE-2026-87719), so upgrading will resolve both vulnerabilities simultaneously.

* For GitLab.com and GitLab Dedicated environments, security patches have already been applied by the provider, so no further action is required.

5-2. Network Access Control and Reducing the Attack Surface

If immediate patching is not possible, minimize the GitLab instance’s exposure to the external internet and restrict access to trusted internal networks or VPNs only. Additionally, limit unnecessary external API access and strengthen access control policies for the management interface and the GitLab API.

5-3. Post-Patch Inspection and Credential Rotation

If a vulnerable version has a history of being exposed to the internet, review relevant logs and credentials, taking into account the possibility of a breach. Since the patch only blocks future file reads, any credentials that may have been exposed must be discarded and reissued.

Check for exposure of critical secrets, such as /etc/gitlab/gitlab-secrets.json
If necessary, reissue key secrets such as `secret_key_base` and invalidate existing sessions
Replace database passwords, Personal Access Tokens (PATs), Deploy Tokens, Runner-related tokens, and SSH keys
Review requests to the Repository Commits API (/api/v4/projects/:id/repository/commits) and the Files API in `api_json.log` and the GitLab Workhorse Access Log
Detect abnormal requests where fixed segments (such as %63(c) and %72(r)) in the URL path are partially encoded—key indicators of Workhorse bypass for this vulnerability
Detect requests where the `file.path` parameter contains server absolute paths such as `/etc/`, `/root/`, or GitLab configuration files
Verify whether actual file contents were transmitted externally by comparing the `written_bytes` value in Workhorse logs with error response information in `api_json.log`

5-4. Web Application Firewall (WAF)-Based Detection and Temporary Blocking

In environments where a web application firewall (WAF) is in operation, apply policies to detect and block abnormal access attempts targeting the Repository Commits API and Files API.

Intensive monitoring of abnormal requests to the /api/v4/projects/*/repository/commits and .../repository/files/* endpoints
Detect and block abnormal percent-encoding in fixed segments of the URL path (e.g., %63ommits, %72epository) - Workhorse bypass attempts that do not occur in normal requests
Detect and block server absolute paths in the `file.path` parameter, such as `/etc/`, `/root/`, `.ssh/`, `gitlab-secrets.json`, and `gitlab.yml`
Typical path traversal strings such as ../, %2e%2e, and %252e%252e are also applied as secondary detection criteria
Apply rate limiting and temporary blocking to repeated Repository Commits API requests originating from the same source

---

6. Conclusion

CVE-2026-85706 is a critical vulnerability that allows an unauthenticated remote attacker to exploit path validation and authentication flaws in the Repository Commits API to steal sensitive files from within the GitLab server. If the leaked secrets and credentials are exploited in subsequent attacks, the damage could escalate to account and privilege compromise, remote code execution (RCE), and compromise of CI/CD pipelines.

In particular, since this vulnerability is listed in the CISA Known Exploited Vulnerabilities (KEV) catalog and is actively being exploited in real-world attacks, organizations operating self-managed GitLab environments must promptly apply the official security patch and, if vulnerable versions have been exposed externally, review relevant logs and replace critical credentials. It is important to note that this vulnerability can only be fully mitigated through official patches; network controls and web firewalls serve only as supplementary measures to reduce risk.

MonitorLab’s Web Application Firewall can detect and block some abnormal path access attempts and malicious sequence requests that may occur during exploitation of this vulnerability using existing directory traversal blocking patterns. However, since this vulnerability circumvents request preprocessing by using percent-encoded URL path segments instead of typical directory traversal strings, MonitorLab plans to continuously analyze these bypass techniques and patterns of server local file access using `file.path` to enhance detection accuracy.

---

PRODUCT				Company	Support
WAAP	SWG	ZTNA	EDR	Who we are	Contact us
WSPC	CASB			What we do	FAQ
CDN	FWaaS			Career
CDR	DLP
DDoS	RBI
	GenAI Security

Threat Intelligence Report