A GitLab vulnerability in the repository commits API lets an unauthenticated attacker read any file on a self-managed server. GitLab patched it on 10 September 2026 in versions 19.3.2, 19.2.6 and 19.1.8, and CVE-2026-85706 carries a CVSS score of 10.0. Probing began within a day.
Which GitLab Versions Are Affected
Three version ranges are vulnerable, and each has its own patched release. Upgrading within your own branch is enough; you do not have to jump to 19.3.
| Affected range | Patched version |
|---|---|
| GitLab CE and EE 18.7 through 19.1.7 | 19.1.8 |
| GitLab CE and EE 19.2.0 through 19.2.5 | 19.2.6 |
| GitLab CE and EE 19.3.0 through 19.3.1 | 19.3.2 |
Both editions are affected: Community Edition, which is free, and Enterprise Edition, which is the paid build. The flaw sits in the repository commits API, reached through HTTP POST requests to /api/v4/projects/{id}/repository/commits/ carrying file path parameters, according to the security firm watchTowr, which reproduced it independently.
Who Does Not Need to Act
Most GitLab users have nothing to do. GitLab says GitLab.com, the company’s own hosted service, has already been patched, and that customers on GitLab Dedicated, its single-tenant managed offering, need take no action.
The exposure is entirely on self-managed installations — GitLab running on a company’s own servers or cloud accounts, where the organisation controls the upgrade schedule. If your team runs its own GitLab, someone has to install the patch.
What an Attacker Can Actually Read
Any file the GitLab server process itself can read. That is broader than source code, and it is why the score reached the maximum.
- Configuration files: GitLab’s own settings, which frequently contain connection strings.
- Credentials and secrets: tokens, API keys and database passwords stored on disk.
- SSH keys: including keys the server uses to reach other systems.
- Log files: which can expose internal hostnames, paths and user activity.
The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N: reachable over the network, low complexity, no privileges, no user interaction, and a scope change. There is one precondition reported by researchers — the server must host at least one public project.
How Quickly the Attacks Started
Less than a day separated the patch from the first probes.
- 10 September 2026: GitLab releases 19.3.2, 19.2.6 and 19.1.8, and publishes the advisory. The flaw was reported through HackerOne by a researcher using the handle s3ntago, according to GitLab’s advisory as reported by BleepingComputer.
- 11 September 2026, 06:00 UTC: watchTowr’s honeypot network records in-the-wild probing for the vulnerability.
- 11 September 2026: the United States Cybersecurity and Infrastructure Security Agency adds CVE-2026-85706 to its Known Exploited Vulnerabilities catalogue.
- 14 September 2026: the remediation deadline for US federal civilian agencies falls due.
The pattern of a published patch being reverse-engineered into an exploit within hours is now routine for internet-facing developer tooling. Jake Knott, head of threat intelligence at watchTowr, told The Hacker News that this is the second critical GitLab flaw in recent weeks and that the move to indiscriminate mass exploitation is “likely not far away”.
What to Do Now
- Check your version: the running version is shown at /help on your own instance, or in the admin area. Compare it against the table above.
- Upgrade to the patched release in your branch: 19.1.8, 19.2.6 or 19.3.2. This is the only fix.
- If you cannot patch immediately, restrict network access: put the instance behind a VPN or an IP allowlist. Researchers describe this as temporary risk reduction, not a fix.
- Assume disclosure if you were exposed: rotate tokens, API keys, database credentials and SSH keys that the server could read.
- Review access logs for POST requests to the repository commits API carrying unusual file path values, going back to 10 September 2026.
A Second Critical Flaw in the Same Release
The same patch release fixed a second serious bug. The Hacker News reports CVE-2026-87719, an insecure deserialisation flaw in GitLab Enterprise Edition scored at CVSS 9.9, which can disclose Advanced Search configuration details and credentials.
That flaw has not been added to the CISA catalogue and no exploitation has been reported, but administrators upgrading for CVE-2026-85706 close it at the same time.
What Is Confirmed as of 14 September 2026
Confirmed: the patch, the affected ranges, the CVSS 10.0 score, the KEV listing and the federal deadline. Also confirmed is automated probing, observed by watchTowr from 11 September.
Not confirmed: GitLab has not published a count of compromised instances, and no organisation has publicly reported a breach traced to this flaw. Estimates circulating for the number of exposed self-managed instances come from third-party scanning rather than GitLab, and are not reproduced here. This is the second maximum-severity flaw in enterprise software in a week, after the SAP OVERPASS vulnerability, also scored CVSS 10.0, where no attacks had been seen at disclosure.
Frequently Asked Questions
What Is the GitLab Vulnerability CVE-2026-85706?
A path traversal flaw in GitLab’s repository commits API. It combines improper path confinement with missing authentication enforcement, so an attacker who is not logged in can read files from the server.
Which GitLab Versions Do I Need?
19.1.8, 19.2.6 or 19.3.2, depending on which branch you run. Anything from 18.7 up to 19.3.1 outside those releases is affected.
Is GitLab.com Affected?
No. GitLab says its hosted GitLab.com service is already patched and that GitLab Dedicated customers need take no action. The risk is to self-managed installations.
Has the GitLab Vulnerability Been Exploited?
Automated probing was observed from 06:00 UTC on 11 September 2026, and CISA listed it as known exploited the same day. No specific victim organisation has been named publicly.
What If I Cannot Patch Today?
Restrict network access to the instance, for example behind a VPN or an IP allowlist, and plan the upgrade. Security researchers treat this as a stopgap, not a remedy.
