The Cybersecurity and Infrastructure Security Agency confirmed on September 11 that hackers are actively exploiting a maximum-severity flaw in GitLab’s development platform, adding the bug to its Known Exploited Vulnerabilities catalog and giving federal agencies until September 14 to patch.
What to Know?
- CISA added CVE-2026-85706, a GitLab path traversal flaw, to its Known Exploited Vulnerabilities catalog on September 11.
- GitLab assigned the flaw a maximum CVSS score of 10.0 and patched it in versions 19.1.8, 19.2.6, and 19.3.2 on September 10.
- The bug lets unauthenticated users read arbitrary files from vulnerable self-managed GitLab servers, including credentials and secrets.
- Security firm watchTowr said it observed in-the-wild probes against the flaw before GitLab’s patch had even been widely deployed.
- GitLab separately fixed CVE-2026-87719, an information-disclosure flaw in its enterprise edition, in the same release.
How It Happened?
CVE-2026-85706 sits in GitLab’s repository commits API, which failed to enforce authentication or restrict where a requester could point a file path. That combination let an unauthenticated attacker send a crafted request and pull sensitive files off the server, including configuration data, deploy keys, and credentials that could unlock further access to code, cloud infrastructure, or CI/CD pipelines.
GitLab shipped fixes for the community and enterprise editions on September 10, closing the gap in the 19.1, 19.2, and 19.3 release branches. The company assigned the flaw a 10.0 on the CVSS scale, the maximum possible rating, reflecting how little an attacker needs to exploit it.
The gap between disclosure and abuse was short. WatchTowr said its intelligence analysts were “already observing in-the-wild probes” for servers running vulnerable GitLab versions within roughly a day of the patch, warning that attackers could use the flaw to “read local files and configs to obtain credentials, secrets, and sensitive information.” The firm added that based on GitLab’s exploitation history, “the time until indiscriminate exploitation is likely not far away.“
Hong Kong’s Computer Emergency Response Team issued its own advisory on September 14, confirming the flaw was “being exploited in the wild” and urging administrators of self-managed instances to patch immediately.
🚨 On 9/10/26, #GitLab published a critical patch release for GitLab Community Edition (CE) & Enterprise Edition (EE), addressing CVE-2026-85706.
— Rapid7 (@rapid7) September 14, 2026
Exploitation could allow an unauth. user to read arbitrary files from an affected GitLab server. Read on: https://t.co/02BqWYbaK4 pic.twitter.com/lf2djitcxn
A Pattern of Critical GitLab Flaws
CVE-2026-85706 is not an isolated event. GitLab disclosed CVE-2025-0376 in early 2025, followed by three more flaws in April: CVE-2026-1092, CVE-2025-12664, and CVE-2026-5173. In August, GitLab disclosed another critical bug, CVE-2026-19478, which attackers began exploiting within days of its release.
That track record is part of why watchTowr flagged this latest flaw so quickly. Repeated critical disclosures on the same platform give attackers a reason to watch GitLab’s advisories closely and test new patches for exploitability almost as soon as they land.
The Bottom Line
A path traversal bug with no authentication requirement is about as low a bar as an attacker can clear, and CISA’s three-day remediation window for federal agencies reflects that urgency. Any organization running self-managed GitLab CE or EE on a version older than 19.1.8, 19.2.6, or 19.3.2 is exposed to the same risk civilian agencies were told to close by September 14, regardless of whether it operates under CISA’s directive.
Administrators who have not yet upgraded should do so now, then check server logs for requests to the repository commits API with unusual file path parameters, a pattern watchTowr has linked to probing activity. Rotating credentials, deploy keys, and CI/CD secrets that a vulnerable server had access to helps reduce the risk from any file read that may have already occurred, since a patch alone does not undo exposure that happened before it was applied. Organizations running GitLab.com’s hosted service did not need to take action, as the flaw only affected self-managed deployments.
