If you self-host GitLab, patch it today: this one is CVSS 10

· · Security

If your business runs its own GitLab server rather than using GitLab.com, this is the patch to stop and apply today. A newly disclosed flaw lets an attacker read files off that server without logging in at all, and researchers are already watching it get probed across the internet.

The bug is tracked as CVE-2026-85706 and rated CVSS 10.0, the maximum score on the Common Vulnerability Scoring System (CVSS), the industry's standard 0-to-10 scale for how bad a security flaw is. A 10 means both parts of the worst case are true: it's trivial to exploit and the damage is total.

What the bug does

The flaw is a path traversal issue, a class of bug where an application fails to check that a filename or path a user supplies stays inside the folder it's meant to. GitLab's own advisory describes it as "improper path confinement and missing authentication enforcement" in the repository commits API. In practice, an attacker sends a single crafted HTTP request to the /api/v4/projects/{id}/repository/commits/ endpoint and the server hands back files it shouldn't, including log files and GitLab's own configuration files, which can contain credentials and other secrets (The Register).

No password, no account, no user interaction. Security firm watchTowr said the only precondition is that the GitLab instance has at least one public project. Its head of threat intelligence, Jake Knott, told The Hacker News this is the second critical GitLab flaw to be exploited within weeks of disclosure, following a GraphQL code injection bug in August, and that "the transition of this vulnerability to indiscriminate mass exploitation is likely not far away" (The Hacker News).

GitLab shipped fixes on 10 September in versions 19.3.2, 19.2.6, and 19.1.8, covering everything from 18.7 up to those builds (GitLab: Critical Patch Release 19.3.2, 19.2.6, 19.1.8). Watchers spotted internet-wide probing starting within hours of that release. The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalog on 11 September, confirming active exploitation and giving US federal agencies until 14 September to patch.

What to do

  • Check your GitLab version now. If you're self-managing GitLab Community or Enterprise Edition anywhere from 18.7 up, you're in the affected range unless you're already on 19.3.2, 19.2.6, or 19.1.8.
  • Upgrade immediately if you're exposed. GitLab.com is already patched and GitLab Dedicated customers don't need to act, but a self-hosted instance is your responsibility to patch.
  • If you can't patch right away, pull the instance off the public internet or restrict access until you can.
  • Check your logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ containing a file.path parameter. That's the signature watchTowr says to look for.
  • If you find evidence of exploitation, assume any secrets stored in GitLab, API tokens, deployment keys, database passwords in CI/CD variables, may be compromised, and rotate them.

How Steelwise can help

Working out which of your self-hosted tools are internet-facing, whether they're patched, and what to rotate if one wasn't is the kind of security review we do for clients. Get in touch.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.