GitLab's CVSS-10 File Read Needs No Login — and the Scanners Are Already Knocking (CVE-2026-85706)

The short version//

GitLab shipped a critical patch release on September 10 — versions 19.3.2, 19.2.6, and 19.1.8 for self-managed CE and EE — headlined by CVE-2026-85706, a path traversal in the repository commits API that GitLab itself scores at CVSS 10.0. The unauthenticated part is what makes it sting: no account, no token, no invite. A stranger with network access sends one crafted request and reads files straight off your server — anything the GitLab service account can see, which on a box full of CI pipelines usually means source code, .gitlab-ci.yml secrets, SSH keys, database credentials, and cloud tokens.

CISA added it to KEV on September 11 (catalog v2026.09.11) with a federal remediation due date of September 14. And the exploitation window is not theoretical: watchTowr's honeypot network was already seeing behavioral probes within a day, and researchers reported internet-wide probing beginning September 11.

What actually broke//

The flaw lives in the repository commits API — the endpoint that applies commit payloads to a project. GitLab's own description: under certain conditions, an unauthenticated user can read arbitrary files from the server. The root cause is improper path confinement combined with missing authentication enforcement on that endpoint — the request's file.path parameter isn't pinned to the repository it claims to be operating in, and nobody asks for credentials first.

For non-GitLab people: this is not a "you need an admin password" bug, or even any-password-at-all bug. It's a file read with CVSS 10.0 through a single HTTP request. Affected versions, per the release notes: everything from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. GitLab.com is already patched; GitLab Dedicated customers need no action. This one is for the self-managed crowd, which includes most of us running code hosting at home or in a small team.

Not their first one this month//

This is not GitLab's first critical self-managed CVE in recent weeks. On August 17, GitLab patched CVE-2026-19478 — a CVSS 9.4 GraphQL code injection that let an unauthenticated user remotely modify or delete public projects and user data — and it was actively exploited almost immediately after disclosure. watchTowr's threat-intel lead called this one "the second instance of a critical-severity GitLab vulnerability in recent weeks" (SecurityWeek). Two unauth-criticals in under a month is less coincidence than pattern: self-hosted code hosts are becoming the new honeypot. Same running theme as our Gitea diffpatch post and the Forgejo compromise postmortem, and it rhymes with today's JFrog Artifactory story. The boxes that hold your software supply chain are exactly where unauthenticated attackers look first.

What you should do//

1. Upgrade to 19.3.2, 19.2.6, or 19.1.8 (or whatever's newer on your supported line) — per the patch release notes. Single-node instances get downtime during DB migrations; multi-node can do it zero-downtime with the proper procedure. The same release fixes 17 other vulnerabilities, including a second critical — CVE-2026-87719, a CVSS 9.9 insecure-deserialization issue in the GraphQL subscription serializer that can expose Advanced Search instance configuration and sensitive credentials (EE) — so this upgrade is doing real work beyond 85706.
2. Hunt your logs for exploitation attempts. watchTowr's guidance: look for HTTP POSTs to /api/v4/projects/{id}/repository/commits/ containing file.path parameters from unauthenticated or unexpected clients. If you see them, treat the box as read — everything in the GitLab service account's reach was readable.
3. Assume-leak posture for what you find. The practical impact is less about the GitLab server itself and more about what it holds: CI/CD secrets, deploy tokens, SSH keys, upstream cloud credentials. Rotate anything that was stored where a file read could grab it — especially if your instance had any internet exposure before Sept 10.
4. Restrict unnecessary internet access to self-managed GitLab while you patch. A Git server reachable from the world is a Git server that gets scanned; the honeypot data says they're scanning right now.
5. If you can't patch today, at minimum firewall the instance or front it with auth — and check whether your CI runners are still pushing to it, because an unpatched GitLab is where your next build's secrets will go to live.