Attackers are exploiting a critical GitLab flaw that lets an unauthenticated network user read arbitrary files from affected self-managed servers. The flaw, CVE-2026-85706, sits in the repository commits API, a public-facing route on a platform that often holds source code and credentials for building and deploying software.
CISA placed the flaw in the federal KEV catalog on September 11 and gave agencies until September 14 to complete the required action. GitLab fixed the affected supported branches in 19.1.8, 19.2.6, and 19.3.2. GitLab.com already runs a patched version, and GitLab Dedicated customers do not need to act on this flaw.
Missing checks exposed server files
GitLab’s September 10 patch advisory attributes the file read to improper path confinement and missing authentication enforcement in the repository commits API. Together, those failures allow a request with no authenticated user to escape the intended file boundary and reach an arbitrary file that the GitLab server can read.
The flaw needs no authenticated account.
GitLab describes the result directly: “an unauthenticated user could have read arbitrary files from the GitLab server.” The company assigns the vulnerability a 10.0 CVSS score with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Researcher s3ntago reported the issue through GitLab’s HackerOne bug bounty program.
The vendor has not published the specific request construction, filenames taken from victim systems, or campaign-specific indicators. CISA’s catalog confirms known exploitation but lists ransomware use as unknown. Neither source quantifies the number of exploited or vulnerable installations.
Figure details
An unauthenticated network request reaches the repository commits API on an affected self-managed GitLab instance. Missing authentication enforcement permits the request to proceed. Improper path confinement then lets the request escape the intended repository boundary and read an arbitrary file available to the GitLab server process. The public sources do not identify the request payload, files taken in observed exploitation, or campaign-specific indicators.
Self-managed branches need immediate patches
The affected range covers GitLab Community Edition and Enterprise Edition from 18.7 up to, but excluding, 19.1.8; the 19.2 branch before 19.2.6; and the 19.3 branch before 19.3.2. GitLab says the scope covers every deployment type when it does not name an exception, including Omnibus, source-code, and Helm chart installations.
Operators should move each affected instance to the latest available patch for its supported branch. The first fixed builds are 19.1.8, 19.2.6, and 19.3.2. After crossing the minimum fixed boundary, continue to the latest patch release for that supported version.
Hosted GitLab has a different exposure decision. GitLab says GitLab.com was already patched when the advisory appeared, while GitLab Dedicated customers require no action. Affected systems are therefore self-managed GitLab CE and EE installations in the published version ranges.
Recognition starts with version and route data
Start with a complete inventory of self-managed GitLab instances and their running versions. Include internet-facing production systems, internal installations, disaster-recovery nodes, staging servers, and administrative instances that may fall outside the primary asset inventory. Classify every build against its branch-specific fixed version.
The repository commits API is the only attack surface GitLab names publicly. Preserve reverse-proxy, web-server, application, and load-balancer request records for that route from the earliest plausible exposure through the upgrade. The sources do not disclose a malicious request signature, so route access alone does not establish exploitation. It does preserve the evidence needed to evaluate unusual unauthenticated requests if GitLab, CISA, or an incident responder later publishes a reliable pattern.
Route evidence is therefore worth preserving.
CISA marks forensic triage as required under BOD-26-04 for covered federal systems. It tells stakeholders to evaluate each asset’s internet exposure, follow the directive’s patching and triage guidance, and discontinue use if vendor mitigation is unavailable. Other organizations can use that sequence to prioritize exposed GitLab servers. The September 14 due date applies to federal agencies.
Verify every running GitLab build
After the upgrade, query the version actually served by every GitLab instance and compare it with the first fixed build for that branch. Package or deployment declarations are expected-state claims; the running instance is the produced artifact that confirms what users and attackers reach. The acceptance threshold is zero self-managed instances below 19.1.8 on the oldest supported line, below 19.2.6 on the 19.2 line, or below 19.3.2 on the 19.3 line.
Keep the before-and-after inventory with the production observation time, instance address, deployment type, running version, and upgrade change. For exposed systems, retain the relevant request records and the result of required forensic triage. A clean version inventory confirms the vulnerable build is no longer serving traffic; it does not establish whether exploitation happened before the patch.
The expected final result is that every reachable self-managed GitLab instance reports a fixed or later supported build and no load balancer sends traffic to an older node. Any server that cannot produce that runtime result remains exposed until it is upgraded or removed from service. Incident scope remains an evidence question because the public record supplies no campaign-specific indicator or universal compromise test.