GitLab's Maximum-Severity Flaw Under Active Attack Hours After Patch Release

A critical path traversal vulnerability in GitLab carrying a perfect CVSS score of 10.0 is already being actively exploited in the wild — with federal agencies given just days to patch before a hard deadline.

GitLab confirmed on September 11, 2026, that CVE-2026-85706 allows unauthenticated attackers to read arbitrary files from exposed GitLab servers. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog the same day it was disclosed — a rare and urgent signal of how serious the threat is.

The vulnerability sits at the heart of one of the most widely used DevOps platforms in the world. GitLab hosts source code, CI/CD pipeline secrets, and deployment credentials for thousands of organisations globally. A flaw of this magnitude is not simply a patching problem — it is a potential supply chain catastrophe waiting to unfold.

---

What the Vulnerability Does and Who Is at Risk

CVE-2026-85706 is a path traversal flaw in GitLab's repository commits API. It stems from what GitLab describes as "improper path confinement and missing authentication enforcement in the repository commits API." That means an attacker with no credentials whatsoever can send a crafted request and retrieve sensitive files directly from the server.

Affected Versions

The affected versions span a wide range of GitLab Community Edition (CE) and Enterprise Edition (EE) installations:

• All versions from 18.7 before 19.1.8
• All versions from 19.2 before 19.2.6
• All versions from 19.3 before 19.3.2

According to preemptive exposure management firm watchTowr, active probes began as early as 06:00 UTC on September 11, 2026 — within hours of public disclosure. The exploitation bar is remarkably low. Only one condition must be met for an attack to succeed.

"Exploitation requires just one requirement: at least one public project must exist," said Jake Knott, head of threat intelligence at watchTowr, in a statement shared with The Hacker News.

What Attackers Can Access

What attackers can access is deeply concerning. Successful exploitation can expose log files, GitLab-specific configuration files, credentials, and secrets stored on the server. Understanding the full scope of exposure requires a structured approach — organisations that have not yet conducted a formal vulnerability assessment across their infrastructure are operating with a significant blind spot, particularly when self-managed GitLab instances are involved.

In a follow-up update after the initial disclosure, Knott confirmed that threat actors had moved well beyond reconnaissance.

"Over the weekend, we also observed threat actors dumping config files for secrets along with system SSH configurations for the victim system," Knott said. "The combination is, as you can imagine, potent as it may allow threat actors the ability to extract passwords, connect to instances that allow password authentication and gain access to the host under the right conditions."

The speed of this escalation — from initial probing to confirmed data exfiltration within a single weekend — underscores just how quickly modern threat actors capitalise on high-value disclosures.

---

A Second Critical GitLab Flaw Compounds the Danger

CVE-2026-85706 is not the only serious vulnerability patched in this release. GitLab also addressed CVE-2026-87719, a critical insecure deserialization bug affecting GitLab EE with a CVSS score of 9.9.

The Insecure Deserialization Bug

This second flaw targets authenticated users with Duo Chat access. According to GitLab, it "could allow an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument to bypass serialization and perform server object lookup."

Both vulnerabilities are patched in GitLab versions 19.3.2, 19.2.6, and 19.1.8.

Knott was direct in placing this incident within a troubling pattern of recent GitLab security events.

"This is the second instance of a critical severity GitLab vulnerability in recent weeks, following the previous GraphQL code injection — CVE-2026-19478 — that was almost immediately actively exploited," Knott said.

Why GitLab Is Such a High-Value Target

The appeal of GitLab as a target for sophisticated threat actors is not difficult to understand. Unauthorised access hands an attacker source code, CI/CD secrets, credentials, and the ability to inject malicious code directly into build pipelines — poisoning everything downstream.

As software supply chain attacks have dominated headlines throughout 2026, GitLab instances represent a particularly high-value target. For organisations relying on GitLab as a core part of their development infrastructure, the risk extends far beyond the platform itself. Securing web-facing applications and services becomes exponentially more difficult when the tools used to build and deploy those applications have been compromised at the source.

The downstream consequences of a poisoned CI/CD pipeline can propagate silently across an entire software supply chain before any detection occurs.

---

Federal Deadline Set as Exploitation Escalates

CISA's Mandate and the Three-Day Window

CISA's decision to add CVE-2026-85706 to its KEV catalog on September 11, 2026, carries real regulatory weight. Federal Civilian Executive Branch agencies are mandated to apply the fix by September 14, 2026 — a three-day window that reflects the severity of active exploitation already underway.

For private sector organisations running self-managed GitLab instances exposed to the internet, watchTowr's warning is direct: the window to act is closing fast.

"Based on the history, the transition of this vulnerability to indiscriminate mass exploitation is likely not far away, and defenders have limited time to act," Knott said.

Immediate Mitigation Steps

Organisations unable to patch immediately should restrict public access to their GitLab instances as a temporary mitigation. Security teams are also advised to review server logs for HTTP POST requests targeting /api/v4/projects/{id}/repository/commits/ URIs that contain file.Path parameters — a potential indicator of exploitation attempts already in progress.

A mature vulnerability management process is essential here — not just for triaging this specific flaw, but for ensuring your organisation can respond at speed when the next zero-day surfaces. The cadence of critical disclosures throughout 2026 makes that capability non-negotiable.

What Security Teams Should Do Now

For security teams and IT administrators, this situation demands immediate action across three fronts.

1. Patch without delay. Apply the GitLab patches to versions 19.3.2, 19.2.6, or 19.1.8 — particularly for any internet-facing self-managed instances. GitLab's official security release advisory provides full technical detail and upgrade guidance.

2. Audit your environment. Review your GitLab environment for public projects that could lower the exploitation threshold. Examine access controls on CI/CD secrets and stored credentials, and assess whether any sensitive configuration data is accessible through the affected API.

3. Treat log review as active defence. Reviewing POST requests to the affected API endpoint is not an optional forensic step — it is a frontline detection measure. Evidence of targeting may already exist in your logs. Act on it accordingly.

The escalation from behavioural probing to confirmed data exfiltration within a single weekend is not an anomaly — it is the new baseline for how rapidly threat actors move once a high-value vulnerability enters public knowledge.