Unauthenticated path traversal and arbitrary file read in GitLab CE/EE

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2 that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.

GitLab CE/EE is identified as affected in these release branches:

• Branch 18.7: all versions from 18.7 before 18.11.12.
• Branch 19.0: all versions before 19.0.9.
• Branch 19.1: all versions before 19.1.8.
• Branch 19.2: all versions before 19.2.6.
• Branch 19.3: all versions before 19.3.2.

GitLab confirms that GitLab.com and GitLab Dedicated are patched. Only the ranges above are established as affected in the available evidence; self-managed deployments should still be checked against their actual branch and patch status.

GitLab CE/EE's repository commits API accepts attacker-controlled path parameters associated with upload data. The confirmed weakness is CWE-22: path confinement is insufficient and authentication enforcement is missing on the vulnerable path, so an unauthenticated caller can cause Rails to open a server-side path instead of the expected temporary upload or metadata file. GitLab's technical guidance identifies file.path as the primary parameter and metadata.path as a sibling parameter in multipart requests; the same primitive can also be reached through the repository files API. The primary network entry point is POST /api/v4/projects/:id/repository/commits, and the vulnerable processing does not require a multipart body because the endpoint can also be reached with an application/x-www-form-urlencoded body. Reading the file and disclosing its contents are separate events: the server reads the selected path, but data reaches the client only when request-parser percent-decoding fails and the resulting error message contains a fragment. The exact internal code change and the complete conditions that determine which bytes are returned are not established by the record; GitLab support guidance requires correlating api_error with Workhorse written_bytes to determine what was actually sent.

The vulnerable path is network reachable through the repository commits API; GitLab's detection material also identifies the repository files API as a reachability path for the sibling parameter. The normalized record describes no required authentication, no user interaction, and low attack complexity. GitLab support notes that the primary request can be processed without a multipart body. The issue has been added to the Known Exploited Vulnerabilities catalog, and the supplied record marks public exploit material as available. If an instance does not expose the API anonymously, GitLab's detection guidance notes that a low-privileged authenticated user may still attempt the primitive. Use in a specific ransomware campaign has not been established.

Successful exploitation can create an arbitrary local file-read primitive on the GitLab server. The amount of actual disclosure depends on the file contents and request-parser behavior; the server may have read a file even when no bytes were returned to the client. If sensitive content is returned, credentials in the disclosed fragment may enable access to databases, object storage, SMTP, LDAP, or other connected systems. Exposure of the Rails secret key base or encryption keys may enable session or token forgery and decryption of some stored data, but those are downstream outcomes that depend on which secrets were actually disclosed and are not established for every request. The direct primitive is data reading and does not itself establish service disruption; integrity or access consequences may follow if exposed credentials are abused.

For GitLab Self-Managed, an unauthenticated request can cause the service to read configuration files, secrets, or credentials from the host. If content is returned, the instance secret key base may enable session or token forgery and decryption of stored CI/CD variables or 2FA data. Database credentials and credentials configured for object storage, SMTP, or LDAP may also be exposed, potentially enabling unauthorized access to connected systems and disclosure of source code or intellectual property. A failed request should not automatically be treated as harmless, but every file read should not be treated as successful exfiltration until api_error and written_bytes are correlated. The incident may require investigation, secret rotation, review of third-party systems, and compliance assessment.

1. Upgrade GitLab Self-Managed to the fixed release matching the running branch: 18.11.12, 19.0.9, 19.1.8, 19.2.6, or 19.3.2. Select the fixed release for the affected branch rather than assuming that a fix in one branch protects every other branch.
2. For instances running the 18.11 or 19.0 branches, GitLab provides the security backports 18.11.12 and 19.0.9. GitLab still recommends moving to a supported release stream where feasible because these backport releases contain only the relevant security fixes.
3. If an affected instance was reachable during the exposure period, preserve logs before restarting or upgrading. Correlate api_json.log with Workhorse access logs using correlation_id, and review api_error and written_bytes to determine what content was actually sent.
4. If a disclosed fragment contains credentials or secrets, rotate only the credentials present in that fragment and review authentication activity on related object storage, SMTP, LDAP, or SSO systems. Do not decide whether to rotate credentials based only on HTTP status.
5. If the evidence involves db_key_base or otp_key_base, follow GitLab Support guidance before attempting rotation. GitLab notes that there is currently no supported rotation path for db_key_base.
6. GitLab states that GitLab.com and GitLab Dedicated are already patched and that customers of those services do not need separate action for this fix.

1. Inventory GitLab Self-Managed deployments and compare each installed branch with the affected ranges and fixed releases in the affected_summary and remediation sections.
2. Before restarting or upgrading, preserve relevant evidence, including api_json.log, Workhorse access logs, and nginx logs. For Omnibus, save rotated variants of /var/log/gitlab/gitlab-rails/api_json.log and the Workhorse log; for source and Helm deployments, collect the corresponding Rails, Webservice, and Workhorse logs.
3. In api_json.log, inspect the params field for file.path or metadata.path values that resolve outside the expected Workhorse temporary directories. Percent-decode values and resolve .. segments before comparison; include percent-encoded parameter names and do not rely only on the literal route.
4. Correlate each correlation_id with the Workhorse access entry, then review written_bytes and api_error. An HTTP status code alone is not sufficient to determine whether file contents were returned.
5. If api_error contains a file fragment, treat the log copies as secret-bearing evidence, identify credentials or secrets present in the fragment, rotate the affected credentials, and review authentication logs for related third-party systems. If there is no evidence that content was returned, conclude only that no disclosure evidence was found, not that the file was never read.