GitLab Path Traversal Vulnerability: Patch Now
A critical GitLab path traversal vulnerability, CVE-2026-85706 (CVSS 10.0), lets an unauthenticated attacker read any file off a self-managed GitLab server, including credentials, deploy keys, and CI/CD configuration. GitLab shipped a patch on September 10; CISA added the flaw to its Known Exploited Vulnerabilities catalog the next day, and BSI issued its own warning on September 14 after security researchers observed exploitation attempts within hours of the patch going public.
What Happened
The GitLab path traversal vulnerability sits in the repository commits API endpoint (/api/v4/projects/{id}/repository/commits/). Insufficient path confinement, combined with missing authentication enforcement, lets an unauthenticated visitor request arbitrary files from the underlying server, no account and no valid session required. Because the files a GitLab server holds routinely include CI/CD pipeline variables, deploy keys, and database secrets, a successful read can hand an attacker everything needed for a direct follow-on attack against connected infrastructure.
The flaw affects GitLab Community Edition and Enterprise Edition versions 18.7 through 19.1.7, 19.2.0 through 19.2.5, and 19.3.0 through 19.3.1. GitLab released patched versions 19.3.2, 19.2.6, and 19.1.8 on September 10. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on September 11, citing evidence of active exploitation; security researchers at watchTowr independently reproduced the flaw and reported observing exploitation probes against their own honeypot infrastructure within hours of the patch release.
Why It Matters
Self-managed GitLab is a common choice for DACH Mittelstand manufacturing, automotive, and engineering organizations that keep source control on-premises for compliance or IP-protection reasons, which puts exactly this audience in scope. An arbitrary file read against a GitLab server is rarely the end of an attack: the credentials, tokens, and pipeline configuration it exposes are typically the starting point for a much larger supply-chain compromise, not the objective itself.
What You Should Do Now
- Upgrade self-managed GitLab CE or EE to 19.3.2, 19.2.6, or 19.1.8 today, whichever matches your current release branch.
- Confirm you are not running a version in the affected ranges (18.7–19.1.7, 19.2.0–19.2.5, 19.3.0–19.3.1) across every self-managed instance, including staging and internal-only servers.
- If immediate patching is not possible, restrict network access to the GitLab instance to trusted IP ranges as an interim measure; there is no configuration workaround that closes this vulnerability on an unpatched server.
- Rotate CI/CD variables, deploy keys, and any secrets stored in or accessible from the affected GitLab instance, since a successful exploitation before patching would not be undone by the patch alone.
DIESEC Perspective
This is the fifth self-hosted developer-infrastructure vulnerability we have tracked in 2026 with the same underlying shape: an unauthenticated or low-friction flaw in the platform holding an organization’s source code and secrets, exploited within days of the patch becoming public. Treating “patch the dev-tooling platform” with the same urgency as “patch the firewall” is no longer optional.
Not sure whether your self-managed GitLab instance is on a patched version, or which secrets might already be exposed? Contact DIESEC for a rapid exposure assessment and credential-rotation review.
Sources: The Hacker News | Rapid7
Published: 2026-09-21 | Category: Vulnerabilities & Patches | ~4 min read
