CVE-2026-85706 (CVSS 10.0): GitLab Path Traversal Leaks SSH Keys and CI/CD Secrets — Actively Exploited, Patch Now

If your organisation runs a self-managed GitLab server, stop reading after the next sentence and go patch. CVE-2026-85706 — a CVSS 10.0 unauthenticated path traversal in GitLab Community Edition and Enterprise Edition — lets any attacker with network access to your server read any file on the underlying host with a single HTTP request. No credentials required. No user interaction required. Exploitation started within hours of the patch being released, and CISA has made today, September 14, 2026, the federal remediation deadline.

What Is CVE-2026-85706 and Why Is It a 10.0?

GitLab’s repository commits API endpoint — POST /api/v4/projects/{id}/repository/commits/ — is designed to let authenticated developers interact with repository content. CVE-2026-85706 breaks that design completely. Due to improper path confinement and missing authentication enforcement (CWE-22), an attacker can supply a crafted file.path parameter containing path traversal sequences and cause the server to serve arbitrary files from the underlying host filesystem rather than the scoped git repository.

The only prerequisite: at least one public project must exist on the GitLab instance. In practice, nearly every internet-facing GitLab deployment meets this condition. Security researcher “s3ntago” discovered and responsibly disclosed the flaw through GitLab’s HackerOne bug bounty programme.

The vulnerability scores a perfect 10.0 on the CVSS v3.1 scale because it satisfies the worst-case value for every metric: network-accessible, no complexity, no privileges, no user interaction, complete scope change, and full confidentiality, integrity, and availability impact. It is not a theoretical maximum — active exploitation is confirmed.

What an Attacker Can Steal in One Request

A single malformed HTTP request to an unpatched server can expose any file readable by the GitLab service account. In practice, that includes the crown jewels of your DevOps environment:

• SSH private keys used for server-to-server communication and deployment
• Database credentials from gitlab.rb and database.yml
• CI/CD pipeline secrets — API keys, cloud provider tokens, signing certificates
• Runner registration tokens — which allow an attacker to register a rogue runner
• LDAP and Active Directory bind credentials for enterprise directory integration
• Container registry credentials and deploy tokens
• Application secrets from secrets.yml including OTP encryption keys

The downstream consequence of stolen runner tokens is particularly severe: an attacker who registers a malicious runner can silently tamper with every build artifact produced by your pipelines, inserting malicious code into software your organisation ships to customers or deploys internally. This is a supply chain attack enabled by a single HTTP request — no lateral movement, no privilege escalation, no persistent access on the server required before poisoning begins.

For context on how frequently software supply chain attacks exploit developer infrastructure vulnerabilities, see our earlier coverage of CVE-2026-60004: Gitea RCE Actively Exploited — Patch Your Self-Hosted Git Server. GitLab CVE-2026-85706 follows the same attack model at a larger scale.

The Patch-to-Exploit Timeline: Under 24 Hours

The speed of exploitation after disclosure is the most operationally alarming aspect of this vulnerability.

Date / Time	Event
September 10, 2026	GitLab releases emergency patches (19.3.2, 19.2.6, 19.1.8) and publicly discloses CVE-2026-85706
September 11, ~06:00 UTC	WatchTowr confirms internet-wide probing of GitLab instances for the path traversal pattern
September 11, 2026	CISA adds CVE-2026-85706 to the KEV catalog; Binding Operational Directive 26-04 obligations triggered
September 14, 2026	Federal FCEB agency remediation deadline — and the day you are reading this

This pattern — public patch releasing information that reverse engineers trivially into an exploit — is increasingly common. According to Rapid7’s Emergent Threat Response analysis, “the transition to indiscriminate mass exploitation is likely not far away.” Every hour of delay increases exposure.

A co-patched vulnerability, CVE-2026-87719 (CVSS 9.9 insecure deserialization in GitLab EE’s GraphQL subscription serialiser), was fixed in the same release. While it requires authentication and has not yet been exploited in the wild, it should be treated as pre-exploitation-stage given the scrutiny the September 10 patch batch has already attracted.

Affected Versions at a Glance

Vulnerable Range	Fixed Version	Deployment Type
18.7.x – 19.1.7	19.1.8	Self-managed only
19.2.0 – 19.2.5	19.2.6	Self-managed only
19.3.0 – 19.3.1	19.3.2	Self-managed only

GitLab.com (SaaS) and GitLab Dedicated users: no action needed — GitLab patched these environments automatically before public disclosure.

The Zero-Trust Perspective: Why “Behind the Firewall” Isn’t Good Enough

Many organisations assume that placing GitLab on an internal network provides adequate protection. CVE-2026-85706 exposes the flaw in that reasoning. The vulnerability requires no authentication — which means a threat actor who has already achieved any foothold on the internal network, or who can reach the GitLab API through a misconfigured proxy or VPN split-tunnel, can immediately escalate to full credential theft.

The stolen CI/CD runner tokens and deploy keys are then used to move laterally into production infrastructure, cloud environments, or customer-facing systems — entirely bypassing perimeter controls. As we explored in our analysis of AI Agents Breaching an Enterprise Network in Under 10 Hours, automated attackers exploit exactly this kind of trust relationship: once inside the developer toolchain, the entire software delivery pipeline becomes an attack surface.

A proper zero-trust posture for DevOps infrastructure means: continuous authentication at every API endpoint, least-privilege access for CI/CD service accounts, network micro-segmentation isolating the GitLab server, and secrets management systems (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) that ensure pipeline credentials are never stored in plaintext on the server. The ICS zero-trust principles we covered in CVE-2026-3869: Schneider Electric Modicon M580 apply with equal force to DevOps platforms: assume breach, verify everything, minimise blast radius.

What You Should Do Right Now

This is not a vulnerability you can defer to the next maintenance window. Here is a prioritised action plan:

1. Patch immediately. Upgrade to GitLab 19.3.2, 19.2.6, or 19.1.8 depending on your current branch. Single-node Omnibus deployments will experience brief downtime during the database migration; plan for it, but plan for it today. Do not wait for a change advisory board meeting.
2. Assume compromise if patching was delayed past September 11. Internet-wide probing began the morning after the patch. If your server was internet-reachable and unpatched for any period after September 10, treat it as potentially compromised and begin forensic review in parallel with patching.
3. Rotate all secrets exposed on the server. After patching, rotate: SSH deploy keys, CI/CD variables, runner registration tokens, database passwords, LDAP/AD bind credentials, container registry credentials, and any API tokens stored in GitLab configuration files.
4. Hunt for exploitation evidence. Search your GitLab HTTP access logs for POST requests to /api/v4/projects/*/repository/commits/ with file.Path or file_path parameters containing sequences like ../, %2e%2e, %2f, or absolute paths outside the repository root. GitLab has released Snort SIDs to assist with network-level detection.
5. Restrict public projects temporarily if immediate patching is impossible. Removing the only prerequisite (a public project) eliminates the attack surface for unauthenticated exploitation until you can patch.
6. Block GitLab API access from untrusted networks. Even for internal deployments, ensure that /api/v4/projects/*/repository/commits/ is not reachable from guest Wi-Fi, contractor networks, or internet-facing segments.
7. Address CVE-2026-87719 for GitLab EE deployments. Rotate Duo Chat service credentials and review GraphQL subscription handler configurations.

India-specific note: India’s large IT services companies — TCS, Infosys, Wipro, HCL, Tech Mahindra, LTIMindtree — and software-product organisations run extensive self-managed GitLab infrastructure for client project delivery and proprietary development. CERT-In’s Directive of April 28, 2022 requires reporting cybersecurity incidents (including unauthorised access) to CERT-In within six hours of discovery. If forensic review reveals exploitation of CVE-2026-85706, incident reporting obligations are immediately triggered. Act now rather than face the dual burden of a breach investigation and a regulatory compliance crisis.

Frequently Asked Questions

Does this affect GitLab.com users?

No. GitLab.com (the public SaaS platform) and GitLab Dedicated (private cloud-hosted instances managed by GitLab) were silently patched by GitLab before public disclosure. You are only at risk if your organisation runs a self-managed GitLab installation — whether on-premises, in a private data centre, or on a cloud VM you manage yourself.

How serious is this compared to other recent vulnerabilities?

CVE-2026-85706 joins a very short list of vulnerabilities scoring a genuine 10.0 and achieving confirmed in-the-wild exploitation within 24 hours of disclosure. Recent examples from this site’s coverage include SonicWall SMA 1000 CVE-2026-83548. The combination of zero-authentication requirement, single-request exploitation, and the downstream supply chain risk from CI/CD credential theft makes this one of the highest operational risk disclosures of 2026.

My GitLab server is internal-only with no internet exposure. Am I safe?

Not entirely. The vulnerability requires network access to the GitLab API, not internet access. An attacker who has compromised any device on your corporate LAN — through phishing, a supply chain attack, or lateral movement from another internal system — can immediately exploit CVE-2026-85706 to escalate access. Patch regardless of your network topology, and review whether your internal GitLab deployment has appropriate authentication controls at the network boundary.

We can’t patch until next week due to change control processes. What’s the fastest risk reduction step?

Two immediate actions reduce risk without a patch. First, remove all public projects (set them to private or internal) — this eliminates the only prerequisite for unauthenticated exploitation. Second, add a web application firewall rule or reverse proxy configuration blocking POST requests to /api/v4/projects/*/repository/commits/ that contain path traversal patterns in any parameter value. Neither is a substitute for patching, but both reduce your exploitability window while approvals are obtained.

Sources and Further Reading

• BleepingComputer — GitLab urges users to patch max severity path traversal flaw
• The Hacker News — GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure
• Rapid7 ETR — CVE-2026-85706: Critical GitLab Path Traversal Exploited in the Wild
• SecurityWeek — GitLab Vulnerability Exploited One Day After Disclosure
• CISA — Known Exploited Vulnerabilities Catalog (CVE-2026-85706 added September 11, 2026)
• WatchTowr — Rapid Reaction: GitLab Critical Path Traversal Vulnerability CVE-2026-85706

---