HomeIntelligenceBrief
VULNERABILITY BRIEF 🟠 High Vulnerability

Critical Path‑Traversal in GitLab (CVE‑2026‑85706) Enables Unauthenticated File and Credential Theft

Recently Patched Flaw Is Being Actively Exploited to Steal Files and Credentials Attackers are actively targeting a recently patched vulnerability in the popular DevSecOps platform GitLab that they can exploit to steal data and credentials from public-facing, self-hosted GitLab servers. The software developer is urging all self-hosted users to update immediately.

Verisq™ Intelligence · 📅 September 14, 2026 · 📰 databreachtoday.com
🟠
Severity
High
VU
Type
Vulnerability
🎯
Confidence
High
🏢
Affected
3 sector(s)
Actions
5 recommended
📰
Source
databreachtoday.com

Critical Path‑Traversal in GitLab (CVE‑2026‑85706) Enables Unauthenticated File and Credential Theft

What It Is

GitLab’s repository‑commits API suffered an “improper path confinement and missing authentication enforcement” flaw. An unauthenticated attacker could craft a request that traverses the file system, allowing read access to arbitrary files on the GitLab server.

Exploitability

The vulnerability carries a CVSS 3.1 base score of 10.0 and is listed in the U.S. CISA Known‑Exploited Vulnerabilities catalog. Threat‑intel feeds confirm active exploitation in the wild, and proof‑of‑concept requests have been shared publicly.

Affected Products

  • GitLab Community Edition (CE) < 19.1.8 (including all 18.7‑19.3 releases)
  • GitLab Enterprise Edition (EE) < 19.1.8 (same release range)

All deployment models (omnibus, source, Helm chart) are impacted. Self‑hosted instances exposed to the internet are at greatest risk; GitLab.com is already patched.

Why It Matters for Compliance & Audit Readiness

Control‑Assurance Lens: The flaw bypasses authentication, directly violating access‑control policies and the “least privilege” principle required by frameworks such as NIST CSF PR.AC‑1 and ISO 27001 A.9.2.1. For organizations that must demonstrate continuous control monitoring, evidence of unpatched, publicly reachable GitLab servers constitutes a material control deficiency. Remediating the issue promptly restores a defensible audit trail, evidences due‑diligence in vendor‑managed software, and aligns with third‑party assurance requirements (e.g., SOC 2 CC6.1).

Recommended Actions

  • Emergency Patch: Upgrade all self‑managed GitLab instances to 19.3.2, 19.2.6, or 19.1.8 (or later).
  • Validate Upgrade: Run GitLab’s built‑in health checks and confirm successful database migrations; use the zero‑downtime procedure for multi‑node clusters.
  • Post‑Patch Verification: Review server logs for anomalous repository‑commits API calls and file‑access events from the patch window.
  • Network Segmentation: Restrict inbound traffic to GitLab to trusted IP ranges or VPN endpoints while the patch is applied.
  • Control Mapping: Document the remediation in your access‑control and vendor‑management control registers; capture patch version, date, and verification evidence for audit purposes.

Source: https://www.databreachtoday.com/in-the-wild-attacks-hit-popular-devsecops-platform-gitlab-a-32810

📰 Original Source
https://www.databreachtoday.com/in-the-wild-attacks-hit-popular-devsecops-platform-gitlab-a-32810

This Verisq Intelligence Brief is an independent analysis. Read the original reporting at the link above.

Vulnerability exposure

Is this CVE in your supply chain?

Verisq matches published vulnerabilities against the software your vendors run, so you know which relationships this touches before the next review.

See vendor exposure →