If your organization writes software or produces code, there is a good chance GitLab is where that work happens. It is the platform used by more than half of Fortune 100 companies and has upward of 30 million registered users worldwide, hosting source code, deployment pipelines, and the credentials that connect them. That is exactly why a vulnerability disclosed on September 10, 2026, deserves immediate attention from technical and non-technical leadership alike.
The vulnerability, tracked as CVE-2026-85706, carries the maximum possible CVSS score: 10.0 out of 10. It allows an attacker, with no login credentials and no prior access, to read arbitrary files off a vulnerable GitLab server. Active exploitation was confirmed within a day of the patch becoming available, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has since added it to its Known Exploited Vulnerabilities catalog.
In plain terms: if you run a self-managed GitLab instance and it is reachable from the internet, this is not a "get to it next sprint" item.
What happened, and when
GitLab released critical patches, versions 19.3.2, 19.2.6, and 19.1.8, on Thursday, September 10, 2026, for GitLab Community Edition (CE) and Enterprise Edition (EE). The release fixed 18 separate security issues, but one stood out immediately: CVE-2026-85706, a path traversal flaw in the repository commits API with the highest severity rating a vulnerability can receive.
GitLab.com, the company's own hosted service, was already running the patched version by the time the advisory went public. GitLab Dedicated customers did not need to take any action. The exposure sits squarely with self-managed instances, the servers that organizations run and patch themselves.
The timeline moved quickly from there. Attack surface management firm watchTowr reported observing in-the-wild probing attempts against the vulnerability starting at 06:00 UTC on Friday, September 11, roughly a day after the patch was published. That same day, CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog and, under Binding Operational Directive 26-04, gave federal civilian agencies until September 14 to secure their systems, a three-day window.
By the weekend, watchTowr reported that activity had escalated beyond probing: threat actors were successfully identifying vulnerable instances and exfiltrating configuration files containing secrets, along with system SSH configuration data.
What is CVE-2026-85706?
The vulnerability lives in GitLab's repository commits API, the interface GitLab uses to serve information about commits within a project. According to GitLab's advisory, the root cause is a combination of two problems: improper path confinement, meaning the API does not properly restrict which files on the server it is allowed to access, and missing authentication enforcement, meaning a request that should require a logged-in user does not actually get checked for one.
Put together, these two gaps mean an unauthenticated attacker can send a request to the commits API and, instead of receiving commit data, retrieve the contents of arbitrary files elsewhere on the server's filesystem.
According to watchTowr's research, the only precondition for exploitation is that at least one public project exists on the target GitLab instance, a very common condition for any organization using GitLab for open-source work, community contributions, or simply a handful of publicly visible repositories.
What can an attacker actually get?
This is not a narrow information leak. Files an attacker could read from a vulnerable server include:
Application and server log files. These frequently contain authentication tokens, session identifiers, and other data that was never meant to leave the server.
GitLab configuration files. These can hold database credentials, integration secrets, and API keys used to connect GitLab to other systems.
SSH configuration data. watchTowr specifically flagged that attackers have been observed pulling SSH configuration files alongside credential material, a combination that, under the right conditions, could let an attacker authenticate directly to the underlying host if password-based SSH access is permitted.
The practical result is that a single, unauthenticated HTTP request can hand an attacker the keys to source code, CI/CD secrets, and credentials, the exact material needed to pivot further into an organization's build pipeline or broader network.
Who is affected?
CVE-2026-85706 affects the following GitLab CE and EE version ranges:
| Branch | Affected Versions | Fixed In |
|---|---|---|
| GitLab CE/EE | 18.7 up to (but not including) 19.1.8 | 19.1.8 |
| GitLab CE/EE | 19.2 up to (but not including) 19.2.6 | 19.2.6 |
| GitLab CE/EE | 19.3 up to (but not including) 19.3.2 | 19.3.2 |
GitLab.com is already running a patched release. GitLab Dedicated customers do not need to take action. The exposure applies to self-managed installations of CE or EE running an affected version.
The vulnerability was reported through GitLab's HackerOne bug bounty program by a researcher known as s3ntago.
Why this one is spreading so fast
This is not GitLab's first brush with rapid post-disclosure exploitation this year. Jake Knott, head of threat intelligence at watchTowr, noted that CVE-2026-85706 is the second critical-severity GitLab vulnerability in recent weeks to be exploited almost immediately after disclosure, following a GraphQL code injection flaw, CVE-2026-19478, that saw the same pattern in August.
A few factors explain why GitLab vulnerabilities tend to move from patch to exploitation this quickly:
Low barrier to exploitation. watchTowr described the attack as achievable with a single HTTP request, no custom tooling or chained exploit required. Bugs this simple to weaponize are attractive to opportunistic scanners as soon as a patch reveals what the flaw looks like.
High-value target. GitLab instances concentrate exactly the kind of material attackers want most: source code, secrets, and CI/CD pipeline access. Knott noted plainly that unauthorized access here can let an attacker poison anything downstream of the platform, a serious concern for supply chain security.
A predictable disclosure pattern. Once a vendor advisory and patch are public, security researchers, and attackers, can often reverse-engineer the vulnerable code path directly by comparing the patched and unpatched versions. For a flaw as straightforward as a path traversal issue, that process does not take long.
Since November 2021, CISA has tagged four separate GitLab vulnerabilities as actively exploited, including two flagged earlier this year. GitLab's scale and value as a target mean this pattern is likely to continue, which makes the speed of your own patch cycle a meaningful part of your risk posture, not just a compliance checkbox.
Other vulnerabilities in the same patch release
CVE-2026-85706 was the most severe issue fixed in this release, but it was not the only critical one. GitLab's September 10 patch addressed 18 vulnerabilities in total. The next most serious:
| CVE | CVSS | Type | Impact |
|---|---|---|---|
| CVE-2026-85706 | 10.0 (Critical) | Path Traversal | Unauthenticated arbitrary file read |
| CVE-2026-87719 | 9.9 (Critical) | Insecure Deserialization | Authenticated Duo Chat users could obtain Advanced Search configuration and credentials |
| CVE-2026-88765 | 8.5 (High) | Buffer Overflow | RCE via crafted project import (Unicode conversion wrapper) |
| CVE-2026-79708 | 8.5 (High) | Insufficient Scope Validation | Developers could access protected CI/CD variables via policy test pipelines |
| CVE-2026-78252 | 8.2 (High) | Cross-site Scripting | Unsanitized Markdown JSON table rendering |
| CVE-2026-13210 | 7.7 (High) | Incorrect Authorization | CI/CD variable scope matcher bypass |
| CVE-2025-14871 / CVE-2026-1168 | 7.5 (High, each) | Denial of Service | Unbounded GraphQL query complexity |
CVE-2026-87719, an insecure deserialization bug in GitLab EE's GraphQL subscription serializer, is worth particular attention for EE customers using Duo Chat since it also allows access to sensitive credentials, though it requires an authenticated session to exploit, which is a meaningfully higher bar than CVE-2026-85706's unauthenticated path.
The remaining ten fixes address medium- and low-severity issues across SAML SSO enforcement, package registry authorization, namespace transfers, compliance framework access controls, and the Terraform state API. Upgrading to the patched releases resolves all 18 issues in a single action.
What should you do?
1. Determine your exposure
Check the version of your self-managed GitLab instance:
sudo gitlab-rake gitlab:env:info | grep -i "gitlab version"
Or check directly from the admin area at /help on your instance. If you are running any version in the affected ranges (18.7 through 19.1.7, 19.2.0 through 19.2.5, or 19.3.0 through 19.3.1), you are exposed.
2. Patch immediately
Upgrade to the fixed release for your branch: 19.1.8, 19.2.6, or 19.3.2. GitLab's official update guidance is available on the Update page, and the full advisory with per-CVE detail is on GitLab's patch release page.
Be aware that this patch includes database migrations. Single-node instances will experience downtime during the upgrade, since migrations must complete before GitLab can restart. Multi-node instances following GitLab's zero-downtime upgrade procedure can apply the patch without an outage.
After upgrading, confirm the running version:
sudo gitlab-rake gitlab:env:info | grep -i "gitlab version"
3. If you cannot patch immediately, restrict exposure
If an immediate upgrade is not possible, reduce your attack surface while you prepare the update:
Remove or restrict public project visibility. Since exploitation requires at least one public project on the instance, temporarily setting all projects to private or internal visibility removes the precondition attackers need, though this is a mitigation, not a fix, and should not replace patching.
Restrict network access to the instance. If your GitLab instance does not need to be reachable from the open internet, placing it behind a VPN, IP allowlist, or reverse proxy with access controls closes off the most common exploitation path.
Front the instance with a WAF. A web application firewall with rules tuned to flag anomalous requests to the repository commits API can add friction, though as with any application-layer control, it should not be treated as a substitute for patching.
4. Hunt for signs of exploitation
Even if you patch promptly, check your access logs for indicators that the vulnerability may already have been probed or exploited before you upgraded. watchTowr specifically recommends reviewing logs for:
grep -E 'POST.*api/v4/projects/[0-9]+/repository/commits/.*file[._]path' /var/log/gitlab/gitlab-rails/api_json.log
Look for HTTP POST requests to /api/v4/projects/{id}/repository/commits/ URIs that include a file.path parameter. This pattern is the signature of an exploitation attempt against CVE-2026-85706. Repeated requests of this shape from a single source, or requests referencing paths outside the expected repository structure such as /etc/, /var/log/, or .ssh/, warrant immediate investigation.
5. Rotate credentials on exposed instances
If your instance was internet-facing and unpatched during the window between disclosure on September 10 and your upgrade, treat any credentials that could plausibly have lived in accessible log files, configuration files, or SSH configuration as compromised. This includes:
- GitLab integration tokens and API keys stored in configuration files
- CI/CD secrets and deployment credentials
- SSH keys and any passwords that may be reachable via SSH configuration data
Prioritize rotation for credentials tied to production systems or systems with broad access, since these represent the highest-impact targets for anything an attacker may have already retrieved.
6. Review the other 17 fixes
Because the patch bundles all 18 fixes together, upgrading resolves CVE-2026-87719 and the remaining medium- and high-severity issues at the same time. There is no reason to patch piecemeal, apply the full update and address all of them in a single maintenance action.
Detection going forward
Unlike memory-corruption vulnerabilities that leave crash logs or unstable processes behind, a path traversal file read of this kind can be silent. A successful exploitation attempt looks, at the network level, like an ordinary API request; the difference is entirely in the file.path parameter and the response contents, which most logging configurations do not capture in detail by default.
If your organization has not already done so, consider whether your GitLab access logs capture full request parameters, not just the endpoint path, since that level of detail is what makes retroactive hunting for this specific flaw possible. Going forward, alerting on the request pattern described above, POST requests to the repository commits API carrying a file.path parameter that references paths outside a project's own repository, is a reasonable addition to any SIEM or log monitoring pipeline that ingests GitLab logs.
Summary
| CVE | CVE-2026-85706 |
| CVSS Score | 10.0 (Critical, v3.1) |
| Type | Path Traversal (unauthenticated arbitrary file read) |
| Component | Repository commits API |
| Affected | GitLab CE/EE: 18.7 before 19.1.8; 19.2 before 19.2.6; 19.3 before 19.3.2 |
| Not affected | GitLab.com (already patched); GitLab Dedicated |
| Precondition | At least one public project on the instance |
| Attack complexity | Trivial, a single HTTP request |
| Reported by | s3ntago, via GitLab's HackerOne bug bounty program |
| Patch released | September 10, 2026 |
| Active exploitation confirmed | Yes, probes from September 11, 2026; escalated to exfiltration by the following weekend |
| CISA KEV status | Added September 11, 2026; FCEB deadline September 14, 2026 under BOD 26-04 |
| Immediate mitigation | Restrict public project visibility; limit network exposure; WAF rules on the commits API |
| Full fix | Upgrade to GitLab 19.1.8, 19.2.6, or 19.3.2 |
| Detection signature | POST requests to /api/v4/projects/{id}/repository/commits/ containing a file.path parameter |
With active exploitation already confirmed by CISA and attackers reportedly moving from probing to actual credential exfiltration within days, this is not a patch that should wait for a scheduled maintenance window. If your GitLab instance is internet-facing, treat this as an emergency change.
If you need help determining whether your GitLab instances are exposed, hunting for signs of prior exploitation, or coordinating credential rotation across affected systems, get in touch. A perfect 10 CVSS score sitting in a platform this central to software delivery is exactly the kind of situation that warrants a same-day response, not a same-sprint one.