Maximum Severity GitLab Flaw Puts Supply Chains at Risk

Maximum-Severity GitLab Path Traversal Already Under Active Attack

GitLab has patched a path traversal vulnerability, tracked as CVE-2026-85706, that scores a perfect 10.0 out of 10 on the CVSS 3.1 scale — the maximum possible severity rating. The flaw lets an unauthenticated attacker read arbitrary files from a vulnerable GitLab server with a single crafted HTTP request, and it was already being probed and exploited in the wild within roughly a day of GitLab's disclosure and patch release.

Because self-managed GitLab instances routinely sit at the center of an organization's software build pipeline — holding source code, CI/CD secrets, and deploy credentials — security researchers are treating this less as a "web app bug" and more as a supply-chain exposure: whoever controls the GitLab server can potentially reach into everything that server builds and ships.

Vulnerability Summary

What Happened

GitLab shipped patched releases — 19.1.8, 19.2.6, and 19.3.2 — for Community Edition and Enterprise Edition on September 10, 2026. The underlying bug sits in the repository commits API and stems from improper path confinement combined with missing authentication enforcement, meaning the endpoint didn't properly restrict which files it was allowed to serve, and didn't require a logged-in session to serve them.

In practical terms, an attacker with no GitLab account and no credentials at all could send a single crafted HTTP request to the commits API and have the application return the contents of files it should never expose — potentially including SSH keys, database credentials, deploy tokens, CI/CD variables, and other sensitive server-side configuration data.

Security firm watchTowr observed in-the-wild exploitation attempts beginning one day after GitLab's disclosure, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 11, 2026 — confirming active exploitation in production environments. For U.S. federal civilian agencies, CISA set a remediation deadline of September 14, 2026, with the vulnerability also flagged for forensic triage requirements under Binding Operational Directive 26-04.

For defenders hunting for signs of compromise, watchTowr's guidance (via Rapid7) is specific:

"Defenders should hunt through log files for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs containing file.path parameters to identify potential exploitation."

The same September 10 patch release also fixed a separate critical deserialization vulnerability, CVE-2026-87719 (CVSS 9.9), affecting Duo Chat/GraphQL, along with 17 other, lower-severity vulnerabilities. Only CVE-2026-85706 has been confirmed as actively exploited so far.

Why It's a Supply-Chain Risk

A self-managed GitLab instance is not just a code editor — for most organizations that run one, it's the control plane for how software gets built, tested, and shipped. A successful exploit of CVE-2026-85706 could hand an unauthenticated attacker:

• Source code for proprietary applications and internal tooling
• CI/CD pipeline variables and deploy tokens, which can be used to push malicious commits or tamper with build artifacts
• Database credentials and SSH keys stored in configuration files reachable through the traversal
• Access to downstream systems that trust artifacts produced by the compromised pipeline

That combination — credential theft plus potential build-pipeline tampering — is what elevates this beyond a simple information-disclosure bug. An attacker who can read CI/CD secrets and inject code into a build pipeline can potentially poison software that an organization then ships to its own customers or partners, extending the blast radius well past the GitLab server itself. Researchers have drawn a direct comparison to CVE-2023-2825, an earlier GitLab arbitrary file-read flaw that also saw active exploitation attempts within days of disclosure — a pattern that suggests attackers specifically watch GitLab advisories for this class of bug.

Mitigation and Patch Guidance

• Patch immediately if you run a self-managed GitLab CE or EE instance: upgrade to 19.1.8, 19.2.6, or 19.3.2 depending on your current release line.
• GitLab.com users do not need to take action — the SaaS platform is already running a patched version. GitLab Dedicated customers likewise do not need to act.
• Plan for downtime on single-node installations. The fixed releases include database migrations; single-node instances will experience downtime while migrations run. Multi-node deployments can use GitLab's zero-downtime upgrade procedure. Of the three fixed releases, only 19.3.2 includes post-deployment migrations.
• Hunt your logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ containing file.path parameters — a strong indicator of exploitation attempts against this specific endpoint.
• Rotate credentials that may have been exposed — SSH keys, database credentials, deploy tokens, and CI/CD variables — if you cannot confirm your instance was patched before exploitation attempts began reaching it.
• Patch CVE-2026-87719 (CVSS 9.9) in the same pass, since it ships in the identical release and affects Duo Chat/GraphQL, even though it has not been confirmed exploited.

Given the combination of a perfect 10.0 CVSS score, no authentication requirement, and confirmed active exploitation, organizations running self-managed GitLab should treat this as an emergency patch, not a routine update cycle.

Sources

• SecurityWeek — GitLab Vulnerability Exploited One Day After Disclosure
• Rapid7 — CVE-2026-85706: Critical GitLab Path Traversal Exploited in the Wild