GitLab CVSS 10 Path Traversal Exploited Same Day as Patch

GitLab shipped patch release 19.3.2 on September 11, 2026, fixing CVE-2026-85706: a path traversal flaw in GitLab Community Edition and Enterprise Edition that allows an unauthenticated remote attacker to read arbitrary files from the server filesystem. CVSS is 10.0. The flaw traces to improper path confinement and missing access controls.

In-the-wild probes were confirmed within hours of disclosure, according to The Hacker News and SecurityWeek. CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog the same day.

What the flaw does

The vulnerability sits in path handling. GitLab is supposed to confine file access to allowed directories; due to improper path confinement and missing authorization checks, an unauthenticated caller can submit a crafted request that escapes those boundaries and retrieves arbitrary files. On a self-managed GitLab instance, that can include repository data, secrets stored in configuration files, CI/CD environment variables written to disk, and anything else readable by the GitLab process.

No authentication. No interaction from any GitLab user. The entire attack surface is the network interface.

Why servers are already being probed

Path traversal vulnerabilities with a public patch drop are predictable targets. The patch itself reveals where the fix landed, and scanning for unpatched instances is straightforward. GitLab is installed at the center of development pipelines: source code, deployment keys, registry credentials, and webhook secrets all typically live on or near the same host. That makes unpatched GitLab servers high-value targets for both automated scanners and targeted actors.

CISA’s KEV addition confirms active exploitation is real, not theoretical. BleepingComputer reports GitLab itself urged immediate patching.

What to do

Upgrade to GitLab 19.3.2 or later. The full affected-version matrix is in the GitLab patch release notes. GitLab.com (the hosted service) was patched at release; the urgency here is for self-managed installations.

If you cannot patch immediately: restrict network access to the GitLab web interface to trusted IP ranges. That reduces exposure to opportunistic scanning while the upgrade is scheduled. It does not fix the flaw.

Confirm patch status with gitlab-rake gitlab:env:info and check the version output. If it reads anything below 19.3.2, the instance is still vulnerable.

Context: GitLab’s recent flaw cadence

This is the third time in 2026 that a GitLab vulnerability has been under active exploitation before most administrators could act. In August, CVE-2026-10053 — an RCE in the package registry — followed a similar disclosure-to-exploitation arc. Earlier, CVE-2026-19478 enabled unauthenticated project deletion via GraphQL. In July, a publicly released PoC for an RCE in GitLab 18.11.3 added pressure on organizations that had delayed patching.

The pattern is consistent: GitLab patches, the patch itself signals where to look, and probes follow. Self-managed installations should treat every critical GitLab advisory as a narrow window, not a “patch next maintenance cycle” situation.