CISA Says Attackers Are Exploiting GitLab’s CVSS 10 File-Read Flaw
CISA says attackers are exploiting CVE-2026-85706, a critical GitLab vulnerability that can let an unauthenticated user read arbitrary files from a vulnerable server. GitLab rates the flaw 10.0 and is telling every affected self-managed customer to upgrade immediately.
The dangerous part is not only the score. GitLab frequently sits beside source code, deployment automation and credentials used to move software into production. An arbitrary file-read weakness on that server can cross boundaries that ordinary repository permissions were supposed to protect.
CISA’s Known Exploited Vulnerabilities catalogue confirms evidence of exploitation. It does not identify an attacker, a campaign or a victim. It also lists known ransomware use as unknown. Organisations should therefore respond to the confirmed attack activity without inventing a breach story that the evidence does not support.
The commits API could reach beyond the repository
GitLab published fixed versions 19.3.2, 19.2.6 and 19.1.8 on 10 September 2026. The company describes CVE-2026-85706 as a path-traversal issue in the repository commits API.
Under certain conditions, GitLab says, an unauthenticated user could read arbitrary files from the server because the API did not keep a path inside its intended boundary and did not enforce authentication correctly. The public advisory does not reveal the required conditions or provide an exploit request.
The vendor’s CVSS 3.1 vector gives the vulnerability a 10.0 base score. It describes a network-reachable attack with low complexity, no privileges and no user interaction. GitLab’s written impact statement directly confirms arbitrary file reading. It does not say that the flaw provides arbitrary file writing, remote-code execution or control of a pipeline.
Which GitLab versions are affected
| Running branch | Affected versions | First fixed version |
|---|---|---|
| 18.7 through 19.1 | All versions from 18.7 before 19.1.8 | 19.1.8, or a later supported fixed branch |
| 19.2 | 19.2 before 19.2.6 | 19.2.6 |
| 19.3 | 19.3 before 19.3.2 | 19.3.2 |
The affected range applies to GitLab Community Edition and Enterprise Edition. When GitLab does not name a particular deployment type, its advisory says all deployment types are affected.
GitLab.com was already running a patched version when the advisory appeared. GitLab Dedicated customers do not need to take action for this release. The immediate operational responsibility falls on organisations running GitLab themselves and on service providers managing self-hosted installations for customers.
Older installations inside the broad 18.7 to 19.1 range should follow GitLab’s supported upgrade path rather than treating 19.1.8 as a drop-in package for every historical deployment. The security destination is a fixed, supported branch whose running version has been verified after maintenance.
CISA changed this from patch priority to incident question
CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 11 September. The catalogue requires US federal civilian agencies to apply vendor mitigations by 14 September and marks forensic triage as required under the current federal directive.
That federal deadline is not a universal legal deadline for every business. The exploitation finding is relevant far beyond government, however. It establishes that vulnerable systems are not facing only a theoretical future risk.
CISA has not published the first exploitation date, request pattern, infrastructure, malware or victim profile. GitLab has not published indicators of compromise in the patch advisory. A lack of matches against a public indicator list therefore cannot prove that an exposed server was untouched.
What an arbitrary file read could place at risk
A GitLab server may hold configuration, application secrets, integration details, logs and material used by deployment workflows. Which files this vulnerability can reach under the undisclosed conditions is not public. It would be inaccurate to claim that attackers have taken any particular secret, repository or customer record.
The business risk comes from the trust concentrated around the platform. If sensitive authentication material was present in a readable location and was accessed, the consequence could continue after the software is patched. Closing the path does not invalidate a copied secret.
This differs from GitLab’s August flaw that could make public projects writable without a login. That earlier vulnerability concerned unauthorised modification or deletion through GraphQL. The new issue is a commits API path traversal that reaches server files, and CISA now confirms exploitation.
What self-managed GitLab operators should do now
- Find every self-managed instance. Include production, development, disaster-recovery, test and customer-hosted systems, plus installations that have stopped reporting to central inventory.
- Record the running version and deployment model. Compare the actual version with GitLab’s affected ranges. Do not rely on the date of the last maintenance task.
- Upgrade immediately through a supported path. Move to 19.1.8, 19.2.6, 19.3.2 or a later supported fixed release, following GitLab’s documented sequencing and backup requirements.
- Verify the result. Confirm the running version on every node after the change. Check replicas, background-job nodes and other components rather than recording success from one front end.
- Preserve useful evidence. Retain reverse-proxy, web, application, audit and operating-system logs before rotation or rebuild. Note the period during which the instance was both vulnerable and reachable.
- Review commits API activity. Look for unauthenticated or unusual requests, unexpected path patterns and source addresses that do not fit normal use. Treat anomalies as leads for investigation, not automatic proof of exploitation.
- Assess sensitive-file exposure. Determine which configuration and secret-bearing files were present and potentially reachable. If evidence or exposure analysis shows that a secret may have been read, rotate it through the supported process and investigate its downstream use.
- Escalate credible signs to incident response. Examine changes to accounts, runners, integrations, pipelines and connected systems. The vulnerability confirms a file-read path, so any broader conclusion must come from evidence in the affected environment.
What remains unknown
No public primary source currently identifies the attacker, campaign, target profile, number of affected organisations or exploitation volume. CISA records ransomware use as unknown. There is also no public evidence that exploitation produced code execution, altered source code or poisoned software builds.
Those limits matter for accurate reporting, but not for the maintenance decision. GitLab says to upgrade immediately, and CISA says the vulnerability is already being used. For a self-managed source-control platform, the defensible finish line is patched, checked for earlier exposure and able to account for any sensitive material that may have sat behind the vulnerable path.
Sources
- GitLab Critical Patch Release: 19.3.2, 19.2.6 and 19.1.8, published 10 September 2026, exact time not stated.
- CISA Known Exploited Vulnerabilities catalogue JSON feed, catalogue release 11 September 2026 at 19:32:16 UTC. The entry adds CVE-2026-85706 on 11 September with a 14 September federal remediation date, forensic-triage requirement and ransomware use recorded as unknown.
