GitLab’s Critical Patch Closes a Path Traversal Flaw Attackers Are Already Probing

On September 10, GitLab released critical patch releases for several versions (19.3.2, 19.2.6, and 19.1.8) to address 18 security vulnerabilities, two of which were rated critical. One of the two critical flaws allows unauthenticated attackers to read arbitrary files off self-managed GitLab servers without any login attempt. This vulnerability, tracked as CVE-2026-85706, arises from improper path confinement and missing authentication enforcement on the repository commits API.

GitLab has classified it as a vulnerability with a CVSS score of 10.0, indicating the highest severity and the absence of authentication requirements and minimal technical skill needed for exploitation.

The vulnerability affects a wide range of GitLab versions, including CE and EE editions from versions 18.7 to 19.1.7, 19.2.0 to 19.2.5, and 19.3.0 to 19.3.1. This means many self-managed installations are at risk since many of these releases are still in use by organizations. GitLab.com and GitLab Dedicated customers have already been patched, leaving the exposed vulnerability to self-managed installations that have not updated.

The window between the disclosure of the vulnerability and its exploitation has already closed for attackers monitoring for it.

The second critical flaw, CVE-2026-87719, has a CVSS score of 9.9 and impacts only Enterprise Edition. It is an insecure deserialization bug in the GraphQL subscription serializer. To exploit this, an attacker with authenticated access and Duo Chat access can submit a specially crafted GraphQL subscription argument to extract advanced search configuration data and credentials from the system.

These vulnerabilities, combined with others in the release, highlight the extensive attack surface of modern DevOps platforms. As platform vendors add AI features, expand API access, and layer permission models, the potential attack vectors increase significantly. The issue of patch cadence is a critical concern, as once a vulnerability goes public, attackers can rapidly probe and exploit it.

The response to such vulnerabilities needs to be swift and structured, with teams considering their advisory-to-production time and reducing it before the next maximum-severity bug emerges.