Executive Summary

    On September 11th, 2026, CISA added a critical GitLab vulnerability to its Known Exploited Vulnerabilities (KEV) catalog following confirmed exploitation in the wild. Tracked as CVE-2026-85706, the flaw lets an unauthenticated, remote attacker read any file the GitLab service account can access on a self-managed GitLab Community Edition or Enterprise Edition server.  

    GitLab servers hold source code, deployment configuration, and the credentials that drive CI/CD pipelines. Arbitrary file read on that host exposes secrets rather than just data: database credentials, SSH keys, deploy tokens, and pipeline variables that an attacker can reuse to access connected cloud accounts, registries, and production systems are also affected. Self-managed instances exposed to the internet carry the highest risk. GitLab.com and GitLab Dedicated environments were addressed by the vendor and require no customer action. 

    Multiple working proof-of-concept exploits are publicly available, and the attack requires no authentication, no user interaction, and no unusual configuration. Given the trivial exploitation path and the concentration of credentials on a typical GitLab host, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise. 

    Affected Systems or Products

    Product

    Affected Versions

    Fixed Versions

    GitLab CE and EE

    18.7 through 19.1.7

    19.1.8

    GitLab CE and EE

    19.2.0 through 19.2.5

    19.2.6

    GitLab CE and EE

    19.3.0 through 19.3.1

    19.3.2

    Mitigations / Workarounds

    To address this vulnerability, upgrade self-managed GitLab CE and EE instances to 19.1.8, 19.2.6, or 19.3.2, matching the release branch already in use. A single upgrade remediates the vulnerability. Multi-node deployments can use GitLab's zero-downtime upgrade procedure, and of the fixed releases only 19.3.2 carries post-deployment migrations. 

    Where an immediate upgrade is not possible, the following steps reduce exposure: 

    1. 1.

      Restrict network access to the GitLab instance, removing it from public internet exposure or limiting connectivity to trusted IP ranges. 

    2. 2.

      Review whether any project on the instance is set to public visibility, since a public project is the precondition that makes the endpoint reachable without authentication. 

    Treat any instance that was internet-facing and unpatched after September 10th, 2026, as potentially exposed. Rotate secrets stored on or reachable from the GitLab server, including database credentials, SSH keys, deploy tokens, and CI/CD variables. 

    Patches

    GitLab.com and GitLab Dedicated environments have already been updated by the vendor. GitLab has released fixes for self-managed installations, and upgrade details are available in the vendor's patch release notes linked below. 

    Indicators of Compromise

    watchTowr reported detecting probes against its honeypot network beginning at 06:00 UTC on September 11th, roughly one day after the patch became available. Treat any instance that was internet-facing and unpatched after September 10th, 2026, as potentially exposed. 

    Organizations should review web server, reverse proxy, and GitLab API request logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ that carry a file.path parameter. Unauthenticated requests to that endpoint, particularly in bursts or from unfamiliar IP addresses and hosting providers, should be treated as suspicious. Requests referencing configuration files, log files, or key material are the strongest signal of a compromise attempt. 

    Follow any confirmed file read with a credential review. Watch for use of GitLab-held secrets elsewhere in the environment: unexpected CI/CD job runs, new or modified deploy tokens and personal access tokens, SSH authentication from unrecognized sources, and pivoting behavior like logins to cloud or registry accounts whose credentials were stored on the server. 

    Technical Details

    The vulnerability stems from the repository commits API endpoint at /api/v4/projects/{id}/repository/commits/, which accepts a file path from the request and fails to confine it to the repository directory. This endpoint also fails to enforce authentication. This combination lets an attacker supply a traversal sequence in a file.path parameter and read any file the GitLab process can open on the underlying host. 

    The only prerequisite is that the instance hosts at least one public project, which supplies a valid project identifier for the request. No credentials, tokens, or user interaction are needed, and the attack is a single HTTP request against a standard API route. 

    Several fully functional exploit scripts are published publicly, which removes any meaningful barrier to mass exploitation. 

    How Beazley Security is responding

    Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.

    We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.

    If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.

    Sources