Attackers Exploit a Maximum-Severity GitLab Flaw as CISA’s Federal Deadline Lands Today
A maximum-severity GitLab flaw is already being exploited, and it is the second critical GitLab bug targeted within days of disclosure in a matter of weeks.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has given federal agencies until today, September 14, to patch a maximum-severity vulnerability in GitLab’s self-managed software. The flaw, tracked as CVE-2026-85706, carries the highest possible CVSS score, 10.0 out of 10, and lets an attacker with no credentials at all read arbitrary files off a vulnerable GitLab server. Attackers started probing for it within a day of GitLab shipping a fix, the second time in a matter of weeks that a critical GitLab bug has been targeted almost as soon as it became public.
Table Of Content
An Unauthenticated Path to Arbitrary Files
GitLab disclosed the flaw in its own advisory for its September 10 Critical Patch Release, describing it as a path traversal issue in the repository commits API: “GitLab has remediated an issue that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.” The vulnerability’s CVSS 3.1 vector, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, explains why it maxed out the scale: the attack is reachable over the network, needs no special skill or privileges, requires no user interaction, and its confidentiality and integrity impact both rate high.
All self-managed GitLab Community Edition and Enterprise Edition versions from 18.7 up to (but not including) 19.1.8, 19.2.6, and 19.3.2 are affected. GitLab.com and GitLab Dedicated customers were already running the patched version and do not need to take any action. GitLab credited researcher s3ntago with reporting the bug through its HackerOne bug bounty program. Because the affected endpoint requires no authentication, threat intelligence firm watchTowr warned that a single request against the repository commits API could return source code, CI/CD secrets, credentials, or other files the server was never meant to expose.
From Patch to Probing in a Day
GitLab shipped versions 19.3.2, 19.2.6, and 19.1.8 on September 10. By the next day, watchTowr’s threat intelligence unit said it was already picking up “behavioral probes for this vulnerability against Attacker Eye, our global honeypot network, meaning attackers have already successfully reverse engineered and reproduced the vulnerability.” The firm assessed with high confidence that the bug would “rapidly transition to indiscriminate, in-the-wild exploitation given the low complexity of exploitation.”
CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities (KEV) catalog on September 11, one day after GitLab’s patch, and flagged it as requiring forensic triage, BleepingComputer first reported. Under Binding Operational Directive (BOD) 26-04, which sets federal patching deadlines by risk, that gave civilian federal agencies a three-day window to remediate, due today. BOD 26-04 legally binds only Federal Civilian Executive Branch agencies, but CISA said in its advisory that “these types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise,” and it encouraged every organization running self-managed GitLab to treat the KEV listing as a signal to patch now, not just federal ones.
A Second Critical GitLab Bug in Weeks
In August, sxz.io covered GitLab’s emergency patch for CVE-2026-19478, an unauthenticated GraphQL code injection bug that scored 9.4 on the same CVSS scale and also needed an out-of-band fix. Jake Knott, head of threat intelligence at watchTowr, drew the connection directly in remarks to SecurityWeek: “This is the second instance of a critical-severity GitLab vulnerability in recent weeks, following the previous GraphQL code injection (CVE-2026-19478) that was almost immediately actively exploited.” He added that the appeal to attackers is obvious, since unauthorized access to a GitLab instance can expose source code, CI/CD secrets, and credentials, and can let an attacker inject code into build pipelines to poison anything downstream of them.
GitLab’s September 10 release was a large one. Alongside CVE-2026-85706, it fixed 17 other security issues, including a second critical bug, CVE-2026-87719 (CVSS 9.9), an insecure deserialization flaw in the GraphQL subscription serializer that could let an authenticated user with Duo Chat access obtain Advanced Search instance configurations and sensitive credentials through a crafted GraphQL subscription argument. Six more issues in the same release rated high severity, covering everything from remote code execution during project imports to bypasses of protected CI/CD variables.
What to Do Now
GitLab and watchTowr both recommend upgrading every self-managed GitLab CE or EE instance to 19.1.8, 19.2.6, or 19.3.2 (or later) immediately, and removing public internet access to any instance that cannot be patched right away. Defenders who suspect they may already be compromised should hunt through access logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs that include a file.path parameter, the specific pattern both GitLab and watchTowr flagged as the exploitation signature for this bug.








No Comment! Be the first one.