Securify

A maximum-severity vulnerability in GitLab’s repository commits API sent shockwaves through the cybersecurity community this week after attackers began exploiting the flaw within 24 hours of its disclosure. Tracked as CVE-2026-85706 and carrying a perfect CVSS score of 10.0, the bug allows unauthenticated attackers to read arbitrary files from self-managed GitLab servers with a single HTTP request — no credentials required.

CISA responded by immediately adding the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, ordering federal agencies to patch by September 14. For any organization running a self-managed GitLab instance, the message is clear: patch now or assume compromise.

How the Vulnerability Works

The flaw resides in GitLab’s repository commits API endpoint at /api/v4/projects/{id}/repository/commits/. Due to what GitLab described as “improper path confinement combined with missing authentication enforcement,” the endpoint fails to properly validate file.path parameters in HTTP POST requests. An attacker can craft malicious path traversal sequences to escape the intended repository directory and read any file accessible to the GitLab process on the underlying server.

The attack is devastatingly simple. There is one prerequisite: the target GitLab instance must host at least one public project — a condition met by the vast majority of internet-facing installations. With that in place, an attacker needs only a single HTTP POST request containing a crafted file.path parameter to retrieve sensitive files from the server’s filesystem.

Security firm watchTowr, which independently reproduced and validated the flaw, confirmed that the types of files exposed can include SSH private keys, database credentials, deploy tokens, CI/CD pipeline variables, cloud access keys, and application configuration files containing secrets. In short, it is a skeleton key to the crown jewels of any organization’s DevOps infrastructure.

Affected Versions and Patches

The vulnerability affects a broad range of GitLab Community Edition (CE) and Enterprise Edition (EE) versions:

• Versions 18.7 through 19.1.7
• Versions 19.2.0 through 19.2.5
• Versions 19.3.0 through 19.3.1

GitLab released patched versions 19.3.2, 19.2.6, and 19.1.8 on September 10–11, 2026. The company urged all administrators to upgrade immediately, noting that the updates include database migrations and that single-node deployments should expect brief downtime during the upgrade.

Exploitation in the Wild — Within Hours

What makes this vulnerability particularly alarming is the speed at which attackers moved. watchTowr reported detecting the first in-the-wild exploitation probes beginning at approximately 06:00 UTC on September 11 — less than 24 hours after GitLab’s public disclosure. By the following day, watchTowr warned that “mass exploitation of the vulnerability is likely to follow shortly.”

This rapid weaponization follows a troubling pattern. SecurityWeek noted that CVE-2026-85706 marks the second critical GitLab vulnerability to be exploited almost immediately after disclosure in recent months, following CVE-2026-19478, a GraphQL code injection flaw that was also “almost immediately actively exploited.” The trend suggests that threat actors are closely monitoring GitLab security advisories and have pre-positioned scanning infrastructure ready to identify vulnerable instances the moment a new CVE drops.

A proof-of-concept exploit has also surfaced publicly, further lowering the barrier for exploitation and expanding the pool of potential attackers beyond sophisticated threat groups to opportunistic criminals.

The Bigger Picture: Why This Matters

GitLab is a cornerstone of modern software development. Millions of organizations rely on self-managed instances to host proprietary source code, manage CI/CD pipelines, and store deployment secrets. A vulnerability that lets an unauthenticated outsider read arbitrary files from these servers is not just a data breach waiting to happen — it is a supply chain risk.

If an attacker exfiltrates CI/CD variables or deploy tokens, they can potentially inject malicious code into build pipelines, push backdoored artifacts to production, or pivot laterally into cloud environments using stolen access keys. The 2020 SolarWinds attack demonstrated how devastating supply chain compromises can be; a vulnerability like CVE-2026-85706 hands attackers a direct path to that same kind of access.

This release also patched two additional serious vulnerabilities. CVE-2026-87719 (CVSS 9.9) is a deserialization flaw in the GraphQL subscription serializer that could expose Advanced Search credentials, though it requires authenticated access with Duo Chat privileges. CVE-2026-88765 (CVSS 8.5) is a buffer overflow in project imports that could enable remote code execution on Enterprise Edition instances. Together, the three CVEs paint a picture of a particularly dangerous patch cycle.

What You Should Do Now

Patch immediately. Upgrade all self-managed GitLab instances to version 19.3.2, 19.2.6, or 19.1.8. If patching is not immediately possible, restrict public access to your GitLab instance at the network level as a temporary mitigation.

Hunt for compromise. Review your GitLab server logs for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ endpoints containing file.path parameters. Any such requests from external IP addresses should be treated as potential exploitation attempts.

Rotate credentials. If your instance was running a vulnerable version and was internet-accessible, assume that sensitive files may have been read. Rotate all secrets that were stored on the server: SSH keys, database passwords, deploy tokens, CI/CD variables, API keys, and cloud credentials.

Audit your exposure. Inventory all self-managed GitLab instances in your environment, including shadow IT deployments that may not be centrally managed. The presence of even one public project makes an instance exploitable.

The window between disclosure and mass exploitation has collapsed to hours. In 2026, “patch Tuesday” thinking — waiting for a scheduled maintenance window — is a luxury defenders can no longer afford when critical vulnerabilities come with a CVSS of 10.0 and a proof-of-concept already in attacker hands.