A patch that attackers noticed almost immediately
GitLab shipped fixes for a maximum-severity flaw on September 10 and 11, 2026. Within roughly a day, security firm watchTowr's honeypot network was already recording scans for it across the internet, starting around 06:00 Coordinated Universal Time (UTC) on September 11. That gap between patch and probing is the real story here: it is now short enough that reading a changelog and finding the bug yourself, without ever seeing GitLab's own advisory, is a realistic path for an attacker.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalog on September 11 and gave federal civilian agencies until September 14 to patch. That deadline only binds U.S. government agencies, but it is a useful signal of how seriously CISA is treating live exploitation, not just theoretical risk.
What the flaw actually does
The bug is tracked under Common Vulnerabilities and Exposures (CVE) identifier CVE-2026-85706, a path traversal vulnerability in the Application Programming Interface (API) endpoint GitLab uses to serve repository commits. Two things went wrong at once: the endpoint failed to properly confine file paths to the repository it was supposed to serve, and it was missing an authentication check that should have gated access to it in the first place.
The Common Vulnerability Scoring System (CVSS) rated it a perfect 10.0, the maximum score the scale allows. In practice, that score reflects an attacker needing no credentials at all: a request to the commits endpoint, at a path like /api/v4/projects/{id}/repository/commits/, with a manipulated file.path parameter, is enough to read arbitrary files off the server. That includes configuration files and stored secrets, not just repository contents. The one precondition is that the target instance has at least one public project, which is a common setup for open-source teams and many companies running self-managed GitLab.
This affects self-managed GitLab Community Edition and Enterprise Edition installations. GitLab.com's own hosted service is not what this story is about.
Who is exposed
The vulnerable versions span three release lines:
| Line | Vulnerable | Fixed |
|---|---|---|
| 18.x | 18.7 and later 18.x builds | 19.1.8 covers the fix for this line |
| 19.1 | up to 19.1.7 | 19.1.8 |
| 19.2 | 19.2.0 to 19.2.5 | 19.2.6 |
| 19.3 | 19.3.0 to 19.3.1 | 19.3.2 |
GitLab credited a bug bounty researcher using the handle "s3ntago" for the report, submitted through HackerOne, according to BleepingComputer. That is the normal, working version of responsible disclosure: a researcher found it, reported it privately, and GitLab shipped a fix before publishing details. The exposure here comes from the gap between that fix going out and administrators actually applying it, not from any failure in the disclosure process itself.
What to do about it
If your organization runs a self-managed GitLab instance, the immediate steps are straightforward:
- Check your installed version against the table above.
- If you are on an affected build, upgrade to 19.1.8, 19.2.6, or 19.3.2 (whichever matches your release line) now, not on your normal patch cycle.
- If you cannot upgrade immediately, review whether your instance needs a public project at all; removing that precondition closes off the specific attack path described above, though it is not a substitute for patching.
- Once patched, check access logs for requests to the repository commits endpoint with unusual or malformed
file.pathvalues in the days before you upgraded, since honeypot data suggests scanning was already underway before most administrators had patched.
Why the timeline matters more than the score
A CVSS 10.0 score gets attention, but plenty of maximum-severity bugs sit unexploited for weeks because they are hard to reach or narrow in impact. This one is different mainly because it is easy to weaponize and the affected software, GitLab, is exactly the kind of internet-facing system that mass scanners are built to sweep for. The one-day gap between patch and probing recorded by watchTowr is consistent with a pattern security researchers have flagged for a couple of years now: attackers increasingly diff a vendor's patched and unpatched code the moment a fix ships, rather than waiting for a public write-up. Treat any GitLab security release from here on as something to act on within hours, not days.
