GitLab on September 10 shipped emergency patches for a maximum-severity vulnerability that lets unauthenticated attackers read arbitrary files off a server and by the following morning, attackers were already hunting for unpatched instances.
The flaw, tracked as CVE-2026-85706, carries a CVSS score of 10.0, the highest rating a vulnerability can receive. It sits inside GitLab's repository commits API, where improper path confinement combined with missing authentication enforcement allows an outside attacker to break out of the intended directory structure and pull files from elsewhere on the server. According to watchTowr, the firm that first flagged in-the-wild activity, those files include log entries and GitLab-specific configuration files that may contain credentials, secrets, and sensitive system details.
The requirement for exploitation is notably low. A GitLab instance needs at least one public project for the attack to work and no credentials are required at all.
"watchTowr Intel is already observing in-the-wild probes for the latest critical GitLab path traversal vulnerability, CVE-2026-85706, which allows attackers to read arbitrary files in a single HTTP request," the firm said on September 11, noting that scanning activity had begun as early as 06:00 UTC that morning, within hours of GitLab's patch publication the day before.
Jake Knott, head of threat intelligence at watchTowr, told this publication: "The appeal to attackers of GitLab is obvious, as unauthorized access allows an attacker to gain access to source code, CI/CD secrets, credentials, and the ability to inject code into build pipelines, gaining access or poisoning anything downstream of it, which as we've seen throughout this year has been a favorite of attackers."
What Gets Exposed
GitLab sits at the center of most software delivery pipelines. A server running GitLab may hold proprietary source code, container build definitions, infrastructure-as-code configurations, API keys baked into CI/CD scripts, deployment credentials, and runner access tokens. A vulnerability that lets an outside party read files off the server without logging in is effectively a master key to an organization's software supply chain.
CISA, which added the vulnerability to its Known Exploited Vulnerabilities catalog on September 11, noted that arbitrary file disclosure can help attackers identify credentials, configuration details, and other information useful for follow-on intrusion activity. The agency also flagged the vulnerability under Binding Operational Directive 26-04, requiring forensic triage because some affected instances may have been accessed before patches were even available.
Knott warned that full-scale exploitation is not far off: "Based on the history, the transition of this vulnerability to indiscriminate mass exploitation is likely not far away, and defenders have limited time to act."
Two More Critical Bugs in the Same Release
The patch bundle that addressed CVE-2026-85706 also closed two additional high-severity vulnerabilities, making this one of GitLab's more consequential security updates in recent memory.
The second issue, CVE-2026-87719, carries a CVSS score of 9.9. It is an insecure deserialization flaw inside the GraphQL subscription serializer that affects only GitLab Enterprise Edition. An attacker who already holds an authenticated account with Duo Chat access can submit a specially crafted GraphQL subscription argument to bypass serialization controls and trigger server-side object lookup, potentially exposing Advanced Search instance configurations and sensitive credentials. Unlike the path traversal issue, this one requires an existing foothold — but an insider, a compromised account, or an attacker who has already gained limited access could use it to escalate what they can see.
A third vulnerability, CVE-2026-88765, is a buffer overflow in GitLab EE's Unicode conversion wrapper with a CVSS score of 8.5 that could allow an authenticated attacker to achieve remote code execution by importing a specially crafted Git project export. The overflow occurs during Advanced Search indexing, which means any instance that accepts project imports is in scope.
All three vulnerabilities are fixed in GitLab versions 19.3.2, 19.2.6, and 19.1.8, released September 10. GitLab.com and GitLab Dedicated customers do not need to take action the fixes were applied on their behalf.
A Pattern That Is Getting Harder to Ignore
CVE-2026-85706 is not an isolated incident. It is the second critical GitLab vulnerability to come under active exploitation within days of disclosure in roughly six weeks.
In August, GitLab released an emergency security update outside its normal twice-monthly schedule to address CVE-2026-19478, a code injection vulnerability in its GraphQL API carrying a CVSS score of 9.4. That flaw allowed unauthenticated attackers to modify or delete publicly accessible projects and user data through a GraphQL directive, requiring no credentials and no user interaction.
WatchTowr warned at the time that it was able to reproduce that vulnerability within minutes of disclosure, armed only with GitLab's advisory details and the patch itself. Exploitation followed within roughly 48 hours.
Knott made the connection explicit: "This is the second instance of a critical-severity GitLab vulnerability in recent weeks, following the previous GraphQL code injection (CVE-2026-19478) that was almost immediately actively exploited."
Internet-wide scanning data puts the number of self-managed GitLab instances reachable on standard web ports at more than 20,000, based on Shodan and Censys lookups, with a meaningful share still running versions inside the vulnerable range days after patches ship. That pool of exposed servers gives attackers a large, persistent target and the repeated pattern of fast exploitation suggests that, at minimum, automated scanning tools are picking up GitLab advisories and moving on them within hours.
What Defenders Need to Do Now
CISA has given Federal Civilian Executive Branch agencies until September 14 to apply the fix. Private sector organizations running self-managed GitLab do not have a regulatory deadline, but the window between disclosure and mass exploitation has been narrowing with each successive GitLab vulnerability this year.
Any internet-facing instance should be treated as potentially compromised until confirmed otherwise if it was exposed before September 10, because active in-the-wild probes began at 06:00 UTC on September 11, meaning any unpatched server was under active attack within hours of the patch release.
Knott recommended a specific log-hunting approach for teams that cannot patch immediately: review HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs containing file.Path parameters. Any hits in those logs before the patch was applied are worth investigating as potential exploitation attempts.
Because successful exploitation can expose sensitive server-side files, organizations with vulnerable internet-accessible instances should also evaluate whether credentials or secrets accessible to the GitLab process require rotation.
Single-node GitLab instances will experience downtime during the upgrade because database migrations must complete before GitLab can start, while multi-node instances can apply the patch without downtime by following proper zero-downtime upgrade procedures. Version 19.3.2 also includes post-deploy migrations that run after the upgrade completes.
The vulnerability was discovered by a researcher using the handle 's3ntago' and reported through GitLab's HackerOne bug bounty program. No attribution for CVE-2026-87719 or CVE-2026-88765 has been publicly confirmed at this time.
