DEV Community

Anoymask
Anoymask

Posted on

GitLab CVE-2026-85706: Active Scanning Targeting Pre-Authentication File Read

#security #threatintel

1. Basic Information

2. Executive Summary

A CVSS 10.0 vulnerability in the commit API of self-managed GitLab allows unauthenticated file reads under specific conditions. Scanning was observed the day after disclosure, requiring the application of patched versions and an investigation into potential sensitive information leaks during the exposure period.

3. Attack Flow

Flow 1: File Read via Commit API

  1. An attacker scans for externally reachable self-managed GitLab instances.
  2. The attacker sends an unauthenticated request to the commit API containing the file.path parameter specifying an out-of-scope path.
  3. If the vulnerability conditions are met, the contents of files on the GitLab server can be read.
  4. Inference: If the read is successful, sensitive information such as tokens included in configuration or logs may be obtained.
  5. Inference: If valid credentials are obtained, unauthorized access to GitLab or integrated services may occur. Based on published reconnaissance information, success up to this point has not been confirmed.

4. Attacker Position and Execution Location

  • An unauthenticated external attacker with network access to GitLab.
  • Inference: After obtaining sensitive information, if valid credentials remain, subsequent operations masquerading as legitimate users or services are possible.

5. Visibility for Victims and Administrators

Victims

  • The attack involves no user interaction or screen display, making it difficult to notice through normal GitLab usage.

Administrators

  • Anomalous unauthenticated POST requests to the commit API and the file.path parameter.
  • Inference: If sensitive information is obtained, token usage from unknown sources, runner registration, and project enumeration become subjects for follow-up investigation.

6. Conditions for Success and Failure

Conditions for Success

  • An attacker can reach a vulnerable self-managed GitLab instance, and the product satisfies the specified conditions.
  • Inference: For file reads to lead to authentication abuse, the readable files must contain valid credentials.

Conditions for Failure

  • Updating to patched versions 19.1.8, 19.2.6, 19.3.2, or later for each series prevents reads caused by this vulnerability.
  • Inference: Restricting API access sources using VPNs or allowlists can suppress attacks from outside the permitted range.
  • Inference: Limiting file permissions and the storage scope of sensitive information can limit the impact of a successful read. Revoking credentials is a separate countermeasure to stop subsequent abuse.

7. What Happens Upon Success

  • If the conditions are met, files on the GitLab server are read prior to authentication.
  • Inference: Depending on the privileges of the read credentials, unauthorized access to repositories, CI/CD variables, artifacts, and runners may occur.
  • Inference: If credentials for integrated services are also obtained, the impact may spread to cloud environments and downstream development and deployment pipelines.

8. Observable Logs

Email

  • User-facing emails are not required for this attack path.

Proxy / SWG / DNS

  • Inference: In reverse proxies or application logs that capture request bodies, confirm unauthenticated POST requests to the commit API and path traversal expressions. URLs alone cannot verify the file.path in the request body.

Endpoint / EDR

  • Inference: If file access is recorded, check for unusual configuration or log reads by the GitLab process. Without records, past reads may not be definitively determined post-facto.

Identity / IdP

  • Inference: Check GitLab-side token usage, runner registration, and administrative operations. External IdP logs alone may not track internal GitLab authentication.

SaaS / Cloud

  • Inference: Depending on configuration, correlate GitLab audit logs with operation history in integrated cloud environments. Whether individual operations such as viewing CI/CD variables are recorded depends on the configuration.

Network

  • Inference: Check unauthenticated request response sizes and subsequent communication. Large responses alone do not confirm file data leakage.

9. Determining Attack Success

The following outlines the scope confirmed in public information and the criteria used for internal organizational investigation.

  • Attack Attempt Observed (Success Unconfirmed): Public Info: watchTowr reported observing active reconnaissance requests in real environments. The success of file reads, authentication, or subsequent compromise in victim environments has not been publicly reported.
  • Data Theft or Session Compromise Confirmed: Criteria: If evidence that out-of-scope file contents were returned as a response exists, it is determined that those files were leaked. This is unconfirmed in public information. File reading is not equated with code execution on the OS.
  • Malware Execution or Authentication Success Confirmed: Criteria: If evidence of successful authentication using acquired credentials exists, it is classified at this stage. Unconfirmed in public information.
  • Subsequent Compromise Confirmed: Criteria: When unauthorized operations on runners, clouds, or downstream CI/CD using stolen credentials are confirmed. Unconfirmed in public information.

10. Investigation Playbook

Triggers

  • Unauthenticated POST requests to the commit API, path traversal strings, or known post-disclosure reconnaissance sources.

Initial Verification

  • Verify the GitLab version, public accessibility, patch timestamp, oldest anomalous request, and response size.
  • Preserve Web, Workhorse, Rails, audit, OS, IdP, and runner logs.

Endpoint and Server

  • Audit GitLab servers for abnormal reads to configurations, sensitive information, and log files, and check web worker child processes and modified files.

Authentication and Cloud

  • Check the usage origin of all access tokens, deploy keys, runner tokens, OIDC/SAML settings, container registries, and cloud authentication keys.

Subsequent Operations

  • Track repository cloning, CI variable viewing, runner additions, pipeline modifications, artifact retrieval, and cloud operations chronologically.

Containment

  • Apply updates or isolate the network, and revoke and reissue potentially leaked access tokens, runner credentials, and external service authentication keys following the issuer's procedures.
  • Do not rotate GitLab database encryption keys using the same method as access tokens. The official Linux package instructions exclude gitlab_rails keys in gitlab-secrets.json from simple rotation targets. If a leak is suspected, verify backups and decryption feasibility, and determine a recovery strategy including product support.
  • Disable suspicious runners and sessions, and verify the integrity of critical repositories and artifacts.

Classification Levels

  • Distinguish between reconnaissance, successful file reads, sensitive data acquisition, authentication success, and supply chain/cloud lateral movement.

11. Defense and Detection Ideas

Single Event

  • Inference: Unauthenticated commit API requests containing ../, multiple variations, or URL-encoded forms.
  • Inference: New runner registration from unknown management sources.

Time-Series Correlation

  • Inference: Correlate unauthenticated API requests -> large responses -> token usage from new sources -> repository/CI variable retrieval.

Threat Hunting

  • Inference: Look back based on the vulnerable version exposure period, including before September 11, 2026, 06:00 UTC, when reconnaissance was reported by media. Examine target API requests/responses and changes in token usage origins.

Log Gaps

  • Determining success is difficult without HTTP bodies, response sizes, token IDs, and OS file access logs.

Priority Countermeasures

  • Inference: Prioritize updates and reducing public exposure scope, proceed with revoking potentially leaked tokens and integrated credentials, and verify runner and artifact integrity. Database encryption keys should be handled separately following official procedures.

12. Facts / Inference / Hypothesis

Facts

  • CVE-2026-85706 stems from improper path restrictions and a lack of forced authentication in the commit API, allowing unauthenticated arbitrary file reads under certain conditions.
  • The affected scope includes GitLab CE/EE from 18.7 prior to 19.1.8, 19.2 series prior to 19.2.6, and 19.3 series prior to 19.3.2.
  • GitLab addressed this in versions 19.1.8, 19.2.6, and 19.3.2. GitLab.com is updated, and GitLab Dedicated is unaffected.
  • SecurityWeek reported that watchTowr observed active exploitation attempts starting September 11, 2026, at 06:00 UTC. watchTowr's public disclosures do not confirm successful file reads or subsequent compromises in victim environments.
  • In the same update, GitLab also fixed CVE-2026-87719, which allowed authenticated users with Duo Chat permissions to exploit insecure deserialization in the GraphQL subscription serializer.

Inference

  • If GitLab configurations or logs are read, subsequent compromises using runner tokens, repository credentials, OIDC/SAML settings, and external service keys may occur.
  • Applying patches alone does not invalidate sensitive information read during the exposure period.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Additional Investigation."

13. MITRE ATT&CK Mapping

  • T1190 Exploit Public-Facing Application (Confidence: High): Exploiting internet-reachable GitLab APIs without authentication.
  • T1552.001 Unsecured Credentials: Credentials In Files (Confidence: Medium): Inference: Searching for credentials in configurations and logs resulting from arbitrary file reads.
  • T1078 Valid Accounts (Confidence: Low): Inference: Subsequent access using stolen tokens or credentials is anticipated, but success is unconfirmed in public information.

14. Unknowns and Additional Investigation

  • Full URIs, payloads, and sender IOCs of exploitation requests.
  • The number of organizations that progressed from active reconnaissance to file acquisition and credential abuse.
  • Details on the specific conditions required to satisfy the vulnerability across various GitLab configurations.
  • Whether reconnaissance requests successfully progressed to sensitive data acquisition and subsequent authentication requires investigation using the target organization's logs and response records.

15. Impact on SOCs and Organizations

For organizations consolidating source code or CI/CD credentials into self-managed GitLab, file read impacts may extend to integrated services. Identify public assets, update them, and correlate API requests and credential usage during the period vulnerable versions were exposed. Do not treat the observed time of reconnaissance as the lower bound of when attacks began.

16. Summary by Role

  • SOC: Correlate unauthenticated POST requests to the commit API, path traversal expressions, and subsequent token usage, runner registrations, and repository retrievals.
  • Administrators: Update to versions 19.1.8, 19.2.6, 19.3.2, or later for each series. Revoke and reissue potentially leaked tokens and integrated credentials, and evaluate database encryption key handling separately without simple rotation.
  • Users: No actions required for normal users. Report unexpected token notifications or suspicious pipeline and repository modifications.

Top comments (0)