Critical GitLab vulnerability allows unauthenticated data exfiltration and is already under attack

A path traversal vulnerability in GitLab has moved from theoretical risk to confirmed exploitation in the field. CVE-2026-85706 affects self-managed instances of GitLab Community Edition (CE) and Enterprise Edition (EE) and allows a remote attacker, without any authentication, to read arbitrary files from the server. The flaw received the maximum CVSS score, 10.0, and has already been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, according to reporting by InfoQ.

For teams running GitLab in production in Brazil, this isn't a generic pending-patch alert: it's a flaw that attackers are already testing against real instances, with a prerequisite so low that a large share of corporate environments qualify without realizing it.

What CVE-2026-85706 exposes

The root cause, according to the technical description cited by InfoQ, is improper path confinement combined with a lack of authentication checks on the repository commits API. In practice, this means the route that should serve files from a specific commit can be manipulated to read any file accessible to the GitLab process.

The most valuable target isn't source code: it's configuration. According to security executive Parker Brisette, the files exposed by this type of flaw are usually exactly what an attacker needs to escalate the attack.

On a GitLab server the arbitrary files are CI/CD variables, runner tokens, and whatever the logs picked up. watchTowr's Jake Knott put the precondition plainly. One public project has to exist. After that there is no authentication step.

Parker Brisette, Chief Information Security Officer

In other words: CI/CD variables, runner tokens, and configuration secrets are the kind of data that leaks through this path, and reading it requires no credentials at all.

The only prerequisite is having a public project

Unlike flaws that depend on exotic configurations, exploiting this one has a simple trigger: the GitLab instance just needs to have at least one public project. That covers instances used for internal open source, public documentation portals, or any self-managed server that has, deliberately or by oversight, a repository with no access restrictions.

The affected versions cover a wide range of GitLab CE/EE:

• 18.7 through 19.1.7
• 19.2 through 19.2.5
• 19.3 through 19.3.1

The flaw was reported by Mohamed Abdelaiz (identified as S3ntago) and fixed by GitLab on September 11, 2026. Security firm watchTowr recorded real-world exploitation probes just hours after the public disclosure, according to InfoQ.

The patch cuts off new reads, but doesn't erase what already leaked

The most important point for anyone administering a GitLab instance isn't just to update: it's understanding that the patch fixes the attack vector but doesn't undo the damage for anyone already exploited before the fix. That's the warning raised by cybersecurity executive Christopher Houser.

Patching stops new reads. It doesn't revoke the deploy tokens, CI variables, and SSH keys an attacker already copied. Rotate those, then check which packages and images your builds pulled while the old credentials were still valid.

Christopher Houser, cybersecurity executive

In practice, for a team running GitLab self-managed, the correct response to this type of CVE has three layers, not one:

1. Update the version (closes the entry point)
2. Rotate deploy tokens, CI/CD variables, and SSH keys (invalidates whatever may have already leaked)
3. Audit builds and images that ran while the old credentials were still valid (checks whether anything malicious entered the supply chain)

That third layer is the one most often ignored, and it's exactly where the risk of CI/CD pipeline compromise and lateral access to other systems that GitLab has permission to touch lives.

How to hunt for exploitation signs in logs

watchTowr recommends that security teams scan HTTP logs for POST requests to routes matching the pattern /api/v4/projects/{id}/repository/commits/ that contain the file.path parameter. That's the trail left by attempts to exploit the flaw, even when the attack wasn't successful.

A user identified as GuffariBranderr8, in a Reddit discussion about the case, reinforced that incident response needs to go beyond applying the patch:

If sensitive configuration or CI/CD credentials are exposed, an attacker could potentially pivot into other systems, so restricting internet exposure and rotating affected secrets solo be part of the response alongside patching.

GuffariBranderr8, Reddit user

Which versions to apply and the backport detail for EOL versions

For self-managed instances, the fixed versions are:

Two weeks after the initial patch, GitLab did something worth noting: it backported the fix to versions 19.0.9 and 18.11.12 of CE and EE as well, even though both lines were already end-of-life. It's a sign of how seriously GitLab's security team treated the CVSS 10.0 score, justifying extra support for versions that, in theory, shouldn't receive any more patches.

For anyone still running one of these EOL versions due to a lack of an upgrade window, the backport buys time, but it doesn't remove the urgency of planning a migration to an actively supported line: the next critical CVE might not get the same treatment.

What's still unclear

InfoQ doesn't provide public numbers on how many instances were actually compromised before the fix, nor does it detail whether GitLab.com (SaaS) was affected the same way or whether the problem is restricted to self-managed deployments, as the reporting indicates. Teams running self-hosted GitLab, especially with active public projects between 18.7 and 19.3.1, are the ones who need to act first: check logs, update, and rotate secrets, in that order.