GitLab's CVSS 10 flaw: one API call and your server files are readable
Vulnerability Management

GitLab's CVSS 10 flaw: one API call and your server files are readable

Mathew Potter

Security Analyst

September 12, 2026

Developers trust GitLab to hold source code, CI secrets, and deployment keys. This week that trust got stress-tested. GitLab patched a maximum-severity path traversal flaw that lets an unauthenticated attacker read arbitrary files from the server through a single POST to the commits API.

What broke and why it is a 10.0

CVE-2026-85706 lives in the repository commits API on self-managed GitLab Community and Enterprise Edition. GitLab's own advisory describes improper path confinement plus missing authentication on an endpoint that should never have been reachable without a logged-in user. In practice, an attacker targets an instance with at least one public project and crafts a request that walks outside the intended directory. Configuration files, keys, and other server-side data become readable.

Fixed versions landed September 10: 19.1.8, 19.2.6, and 19.3.2. GitLab.com is patched. The risk sits with the thousands of self-hosted instances still on older builds. CISA added the CVE to KEV on September 11 with a September 14 remediation date for federal agencies.

How fast attackers moved

watchTowr reported exploitation attempts against honeypots starting around 06:00 UTC on September 11, roughly six hours after public disclosure. That is the new normal for high-impact bugs in widely deployed dev tools. Scanning is indiscriminate. You do not need to be a high-profile target. You need to be internet-reachable on a vulnerable version.

Hunt for POST requests to /api/v4/projects/{id}/repository/commits/ with suspicious file.Path parameters. If you see them in logs from the past 48 hours, assume investigation, not "probably a scanner that failed."

Why this hurts more than a random web bug

GitLab often sits at the center of how software ships. Compromise there can mean stolen deploy tokens, modified pipelines, or quiet access to private repos that never touch a public bug bounty scope. Law firms and professional services shops increasingly run internal GitLab or GitHub Enterprise equivalents for client work. A file read on the app server can expose gitlab-secrets.json, SMTP creds, or OAuth application secrets that unlock the rest of the estate.

What we would do today

  • Inventory every self-managed GitLab instance and confirm version. Patch to 19.3.2, 19.2.6, or 19.1.8 as appropriate.
  • Review web and application logs for the commits API path since September 10.
  • Rotate GitLab secrets, CI variables, and deploy keys if you find suspicious traffic or cannot prove you were clean.
  • Restrict admin and API exposure to VPN or zero-trust paths. "Internal" GitLab on a routable IP is not internal.
  • Add dev infrastructure to your annual assessment scope. It is part of your attack surface even if the security team does not log in daily.

Bottom line

Source control is crown-jewel infrastructure. A CVSS 10.0 with no authentication is a drop-everything patch for self-hosted GitLab. Forensic Five helps Canadian teams scan external exposure, review app and CI configuration, and document posture for clients and insurers. Based in St. Albert, Alberta. Scoped assessments, plain language reports.

Tags

GitLab CVE-2026-85706 devops path traversal CI/CD

Share This Article

About the Author

Mathew Potter

Security Analyst

Mathew leads assessments and consulting at Forensic Five from St. Albert, Alberta. His background is Linux systems, networks, and application infrastructure.