GitLab CVE-2026-85706 Path Traversal Flaw Under Active Attack

What's actually happening

CISA has added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog after confirming attackers are actively abusing a path traversal bug in GitLab's repository commits API. The flaw carries a CVSS v3.1 score of 10.0, the maximum possible rating, and under certain conditions lets an unauthenticated attacker read arbitrary files from a vulnerable GitLab server.

GitLab traced the root cause to improper path confinement combined with missing authentication enforcement in the affected API endpoint. The company shipped fixes on 10 September in versions 19.3.2, 19.2.6 and 19.1.8, and urged self-managed operators to upgrade immediately. Security firm watchTowr said it began observing in-the-wild probes from 06:00 UTC on 11 September, warning that broader exploitation was likely to follow quickly.

Why UK DevOps pipelines are exposed

The affected versions span 18.7 before 19.1.8, the 19.2 branch before 19.2.6, and 19.3 before 19.3.2 for both GitLab Community Edition and Enterprise Edition. GitLab.com is already patched and GitLab Dedicated customers don't need to act, but that leaves every internet-facing, self-managed instance in scope — a common setup for UK organisations running their own build infrastructure rather than the SaaS tier.

The commits API sits at the heart of most CI/CD workflows. A server that can be tricked into leaking arbitrary files can expose source code, configuration files, secrets and credentials — exactly the material that feeds automation pipelines and downstream deployment trust. watchTowr described exploitation as potentially as simple as a single HTTP request, which is a low bar for attackers scanning the open internet.

Immediate actions for infrastructure teams

The priority for any exposed, unpatched self-managed installation is straightforward: upgrade to 19.3.2, 19.2.6 or 19.1.8 today, not on the next scheduled maintenance window. Teams unable to patch immediately should pull internet-facing GitLab instances from public access until they can, per watchTowr's guidance.

Alongside patching, admins should review logs for HTTP POST requests to the /api/v4/projects/{id}/repository/commits/ endpoint containing file.path parameters — the specific pattern watchTowr flagged as evidence of exploitation attempts. Any positive hits should be treated as a potential compromise: standard incident-response practice is to rotate credentials that may have been exposed and review what those credentials could touch across CI/CD, cloud, and downstream systems.

• •Upgrade self-managed GitLab CE/EE to 19.3.2, 19.2.6 or 19.1.8
• •Restrict or remove public access to unpatched internet-facing instances
• •Search logs for suspicious commits API requests with file.path parameters
• •As a standard incident-response precaution, rotate any credentials that may have been stored in exposed repositories or configs

A recurring pattern, not a one-off

This is not GitLab's first maximum-priority scramble of 2026. An earlier flaw, CVE-2026-19478, came under active exploitation in August and required upgrades to 19.2.4, 19.1.6, 19.0.8 and 18.11.11. A July advisory covered an authenticated remote code execution issue fixed in 18.10.8, 18.11.5 or 19.0.2. The cadence suggests self-managed GitLab estates need continuous patch discipline rather than periodic reviews.

CISA's own framing is blunt: "These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise." The agency's binding directive only covers US federal networks, but it explicitly encourages every organisation to prioritise remediation of Known Exploited Vulnerabilities catalog entries regardless of sector.

What this means for procurement and resilience planning

For UK buyers, the practical lesson extends beyond this single CVE. Self-hosted developer platforms need the same patch-and-rollback rigour as production infrastructure — treat repository servers as tier-one assets, not internal tooling. That means clear rollback procedures should an upgrade go wrong, verified through immutable backups rather than assumptions about snapshot integrity.

It's also worth reviewing where GitLab sits in a wider zero trust architecture — an unauthenticated file-read bug is exactly the kind of flaw that segmentation and least-privilege network access limit the blast radius of. Teams weighing whether to keep managing GitLab in-house or hand patch cycles to a specialist should factor incidents like this into IT procurement decisions, and consider third-party maintenance support for legacy or under-resourced self-managed environments that consistently lag behind vendor releases.

The bottom line

A perfect-10 CVSS score, unauthenticated exploitation, active probing within a day of disclosure, and a repository platform that routinely stores source code, secrets and configuration data — this is as close to a worst-case combination as vulnerability management gets. Any organisation running self-managed GitLab CE or EE below the patched versions should treat this as a same-day fix, backed by log review and managed detection & response to catch anything that slipped through before the patch landed.