A flaw in GitLab's commits API lets anyone on the internet read files off a self-hosted server without logging in first. No account, no token, no project membership. GitLab shipped the fix on Thursday, scanners started sweeping for unpatched servers within a day, and on Friday evening CISA added the bug to its Known Exploited Vulnerabilities catalog with a remediation deadline of Monday.
Three days, and two of them are a weekend.
A perfect 10, and what earns one
GitLab's own advisory describes CVE-2026-85706 as an issue where "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." It carries a CVSS score of 10.0, the maximum, on the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Scores that high are rare because they need everything to line up at once: reachable across the network, low attack complexity, no privileges, no user interaction, and a scope change, meaning the damage does not stop at the component holding the bug.
It affects GitLab Community Edition and Enterprise Edition from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. GitLab credits the find to a researcher using the handle s3ntago, reporting through its HackerOne bug bounty program. GitLab.com already runs a patched version and GitLab Dedicated customers need to do nothing, so this is a self-hosted problem, which is also where the interesting repositories tend to live.
One request, and the config file comes back
watchTowr, which published a rapid analysis and has been watching for exploitation against its sensor network, puts the exposure plainly: an attacker can send a request to the commits API and have the application return the contents of files it should never have exposed, including configuration files, secrets and other sensitive server-side data. On a GitLab box that is not a vague category. It is the file holding the database credentials, the secret key base, and the tokens GitLab uses to reach everything else.
A public proof of concept is already circulating. Its author describes the root cause as a disagreement between two parsers rather than a plain traversal string: GitLab Workhorse matches its route regex against the still-escaped path, while Puma decodes percent-encoded characters before the request reaches Grape routing, so the authentication check never runs ahead of the file access. That account is the researcher's and not GitLab's, which has not published detail at that level. The demonstration reads /etc/hostname and then the GitLab Rails configuration file, which is about as direct a path from read primitive to server secrets as it gets. Handle any exploit code you go looking for with care, incidentally, because trojanised proof of concept code aimed at researchers is now a category of its own.
CISA set the clock to Monday
CISA added the flaw to the KEV catalog on 11 September with a remediation due date of 14 September, the compressed window its risk-based directive reserves for the worst cases, and the same three days it handed out when it flagged JFrog, Kestra and Sangoma bugs earlier this month. The catalog lists the bug as requiring forensic triage, so affected agencies are not simply told to patch, they are told to go and check whether somebody got there first. Known use in ransomware campaigns is listed as unknown. A KEV addition is not a severity opinion: CISA adds an entry when it has reliable evidence the flaw is being exploited in the wild.
Patch to 19.3.2, 19.2.6 or 19.1.8, then read your logs
GitLab's advisory offers no workaround, so upgrading is the fix, and the same release closes a second critical rated 9.9, CVE-2026-87719, which makes this a poor release to cherry-pick from. For hunting, watchTowr's guidance is to search access logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ carrying file.path parameters. And if your instance sat internet-reachable and unpatched between Thursday and whenever you upgrade, the cautious reading is that everything in that configuration file should be treated as exposed. Rotating those credentials costs a great deal less than learning later that you needed to.
It has been a rough few weeks for self-hosted GitLab, after an August flaw that let strangers delete public projects. The difference this time is that reading files off a source code server is rarely the end of an attack. It is the credential-gathering step that comes before one.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.