GitLab’s Perfect-10 Vulnerability Is Already Being Probed

A GitLab path traversal vulnerability rated the maximum possible CVSS score of 10.0 is under active reconnaissance on the open internet. That is less than a day after the company shipped a fix. Security researchers spotted the first probes within hours of GitLab’s advisory. That pace leaves little room for self-managed customers to sit on the patch.

What the GitLab path traversal vulnerability actually does

The bug, tracked as CVE-2026-85706, sits in GitLab’s repository commits API. A path handling error, combined with a missing authentication check, is the cause. An attacker who has never logged in can send a crafted request. In response, the server hands back files it was never meant to expose. The only precondition is that the instance has at least one public project. That is a common setup on self-hosted installs used for open documentation or community repos.

The flaw runs with the privileges of the GitLab service account. So the files at risk include configuration data, database credentials, SSH keys and access tokens. A single unauthenticated request can hand an attacker much of what is needed to move further into the environment.

GitLab’s own advisory also patched two related issues in the same release. One is an insecure deserialisation bug in the Enterprise Edition GraphQL subscription serializer, rated CVSS 9.9. The other is a buffer overflow in a Unicode conversion wrapper, rated 8.5. Neither is being exploited yet, but both point to a rough few days for GitLab’s security team.

Who is affected

This GitLab path traversal vulnerability covers GitLab Community Edition and Enterprise Edition. The affected ranges are versions 18.7 through 19.1.7, 19.2 through 19.2.5, and 19.3 through 19.3.1. GitLab.com and GitLab Dedicated customers are already protected, since GitLab patches its own hosted infrastructure centrally. Self-managed instances are different. Many organisations run one to keep source code on their own servers, often for compliance or contractual reasons. Those teams have to apply the update themselves.

GitLab released the fix on 10 September 2026, in versions 19.3.2, 19.2.6 and 19.1.8. There is no workaround. Restricting network access to the instance buys some time. But it is a stopgap, not a fix, because the flaw needs no valid account to exploit.

A fast-moving exploitation timeline

The gap between disclosure and attack attempts is what makes this worth watching closely. Jake Knott, head of threat intelligence at security firm watchTowr, said the shift from scanning to indiscriminate mass exploitation is “likely not far away.” He added that defenders have limited time to act. His team’s honeypot network logged behavioural probes for the flaw from 06:00 UTC on 11 September, the day after the patch went out.

That sequence is now routine for high-severity bugs in widely used software: a patch, then exploitation attempts almost immediately after. Attackers reverse-engineer a fix to work out exactly what it closes off. Then they scan the internet for anyone who has not applied it yet.

The flaw was reported through GitLab’s HackerOne bug bounty programme. The researcher used the handle s3ntago. That responsible disclosure is how GitLab was able to test and ship a fix before the details became public.

Why this matters beyond GitLab users

Source code platforms sit at the centre of the software supply chain. A breach there does not just expose one company’s code. It can expose credentials for cloud accounts, CI/CD pipelines and third-party integrations connected to that GitLab instance. Each one is a potential foothold into a customer’s own systems.

For a UK business running self-managed GitLab, the practical question is simple. Has the instance been patched, and if not, why not. Checking the version number takes minutes. Leaving it exposed for days invites exactly the kind of opportunistic scanning already under way.

Self-managed GitLab is common for a reason. It appeals to organisations that must keep source code on their own infrastructure for compliance or contractual reasons. Think financial services firms, public sector suppliers, and software vendors with customer audit requirements. Those are also the organisations with the most to lose if a single unauthenticated request can read their secrets. That is what makes the fast exploitation timeline behind this GitLab path traversal vulnerability so significant.

What to do now

• Confirm your GitLab version and upgrade to 19.3.2, 19.2.6 or 19.1.8 without delay.
• Review access logs for POST requests to the repository commits API that carry unusual file path parameters. Researchers have flagged this pattern as a sign of exploitation attempts.
• Rotate credentials and tokens stored on the instance if you find any evidence of access before patching.
• Treat internet-facing developer tools with the same urgency as firewalls or VPNs. This incident shows they are just as attractive a target.

None of this requires specialist tooling. It requires someone checking a version number this week, then confirming the box is ticked. That is a small ask given what this GitLab path traversal vulnerability can expose in a source code platform.