GitLab Max-Severity Path Traversal: One HTTP Request Reads Anything on Your CI Server

A maximum-severity flaw in GitLab’s commits API lets anyone read arbitrary files off your CI server, and scanners were already probing for it within a day of disclosure

GitLab shipped patches on Thursday for CVE-2026-85706, a path traversal bug in the repository commits API rated at the maximum severity score. No login required. No token. Under the right conditions, a single HTTP request gets an attacker arbitrary file reads on a vulnerable self-managed instance, and the payloads that hurt most, credentials, API keys, secrets, sit in files this flaw can reach.

The bug was found by a researcher going by “s3ntago” through GitLab’s HackerOne program. The root cause is almost embarrassingly simple: improper path confinement plus missing authentication enforcement in the commits API. The endpoint did not check who was calling, then let file paths escape their directory boundaries.

Scanners arrived before patches did

GitLab had not flagged active exploitation when the advisory went out. That window lasted about a day. watchTowr reported on September 11 that it was already seeing in-the-wild probes for unpatched, Internet-exposed GitLab servers, with attackers reading arbitrary files via crafted requests to the commits API.

watchTowr’s guidance for defenders is specific enough to act on today. Hunt your HTTP logs for POST requests targeting /api/v4/projects/{id}/repository/commits/ URIs that carry file.path parameters. If you find them and cannot name the author, assume compromise until proven otherwise.

A second flaw landed in the same release

The same patch set closes CVE-2026-87719, an insecure deserialization weakness in the GraphQL subscription serializer. It hits GitLab Enterprise Edition, and it needs an account with Duo Chat access to exploit. The payoff is still ugly: stolen credentials and Advanced Search instance configuration. An authenticated bug is not a harmless one, and insider-risk accounts that touch AI features are now part of the blast radius. That is a pattern worth tracking as more shops bolt AI assistants onto their source-code platforms.

Patch now, and check what your instance exposes

Fixed versions are GitLab CE and EE 19.3.2, 19.2.6, and 19.1. GitLab.com already runs the patched code; GitLab Dedicated customers are taken care of. Everyone running self-managed, which is most of us, has work to do.

Two questions to answer before you patch, so you know what you were exposed to:

• Is your GitLab instance reachable from the public internet? If yes, scanners had it in their target lists within 24 hours.
• What lives on that server’s filesystem? Runners often carry registration tokens, deploy keys sit in home directories, and CI variables leak into logs. Treat the box as holding the crown jewels until you have checked.

An unforgivable bug, repeatedly

Path traversal is not a new GitLab problem. CVE-2023-2825, also max severity, was patched in May 2023 and exposed proprietary code, credentials, and tokens on unpatched servers. In 2024, CISA and the FBI jointly told software vendors to eliminate path traversal flaws before shipping, quoting a verdict that has been on the books since 2007: these bugs are “unforgivable.”

CISA has flagged four GitLab vulnerabilities as exploited in the wild since November 2021, two of them added to the KEV catalog this February. GitLab claims more than 30 million registered users and runs inside over half the Fortune 100, names like Nvidia, Airbus, T-Mobile, Lockheed Martin and Goldman Sachs. That install base, plus a patch-public-on-Friday rhythm, is exactly what scanning swarms feed on.

Here is what nags at me: the authentication check was missing. Not bypassed, not broken by a novel technique. Missing. A 2026 advisory for a bug this basic, on a platform this mature, says the API surface grew faster than the review process guarding it. DevSecOps platforms audit everyone else’s code. Who audits theirs before an endpoint goes live?

What eHawu does with this

GitLab’s advisory assumes you can patch today. Half the African enterprises we work with cannot, because the instance belongs to a development team that spun it up years ago and nobody wants to touch the pipeline that feeds production. eHawu sits at the network layer, in front of exactly these boxes. We enforce which sources can reach your CI server at all, so scanning swarms probing /api/v4 endpoints never establish a session, and we alert when an internal host starts pulling data in shapes that look like file reads. Patch windows matter. Until the window opens, the front door should not be open either. Talk to eHawu about network-layer protection for the development infrastructure you cannot afford to expose.