GitLab Commits-API Flaw CVE-2026-85706 Exploited a Day After Patch; CISA Gives 72 Hours

GitLab shipped an emergency patch on 10 September 2026 for a CVSS 10.0 path traversalPath Traversal🛡️A web vulnerability (CWE-22) where user-supplied input in a file path escapes the directory the application intended to serve from, typically via parent-directory references, letting an attacker read or write files elsewhere on the server. bug in its REST API. Attackers were probing for it within hours, and by 11 September CISA had added it to the Known Exploited Vulnerabilities catalog with a three-day remediation deadline. If you run self-managed GitLab and have not upgraded, treat this as an incident, not a maintenance ticket.

What Happened

GitLab's critical patch release for versions 19.3.2, 19.2.6, and 19.1.8 fixes 17 security issues. The headline entry is CVE-2026-85706, a path traversal flaw in the repository commits API. GitLab's own description is blunt: under certain conditions, an unauthenticated user could read arbitrary files from the GitLab server because of improper path confinement and missing authentication enforcement in that endpoint. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N, which is as bad as a file-read bug can score. The weakness is classified as CWE-22. GitLab credits the researcher s3ntago, who reported it through the company's HackerOne bug bounty programBug Bounty Program🛡️A vendor-run program that pays external researchers for responsibly disclosed vulnerabilities, usually through a platform such as HackerOne. Many critical fixes, including GitLab's September 2026 patch release, originate from bug bounty reports..

The disclosure-to-exploitation window was measured in hours. watchTowr reported that its Attacker Eye honeypotHoneypot🛡️A decoy system deployed to be attacked so defenders can observe exploitation attempts safely. Honeypot networks give early warning that a vulnerability has moved from theoretical to actively exploited, often before official catalogs like CISA KEV confirm it. network began seeing behavioral probes for the bug at 06:00 UTC on 11 September, roughly a day after the patch went public. Jake Knott, watchTowr's head of threat intelligence, described exploitation as a single HTTP POST to the project commits endpoint carrying a crafted file path parameter, and said the only precondition is that the target instance host at least one public project. He also warned that indiscriminate mass exploitation was likely to follow shortly.

CISA added CVE-2026-85706 to the KEV catalog on 11 September with a due date of 14 September under BOD 26-04. The feed's catalog version 2026.09.11 added three other entries the same day: a ConnectWise ScreenConnect privilege management bug (CVE-2026-84869) and two JFrog Artifactory authentication and authorization flaws (CVE-2026-42016 and CVE-2026-42018). NVD published the GitLab record on 12 September and still shows it in Received status, so the analysis fields there are GitLab's own, not NIST's.

Who Is Affected

The vulnerable range is wide. GitLab lists Community Edition and Enterprise Edition from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. That covers every self-managed release from roughly the start of 2026 forward. GitLab.com already runs the patched code, and GitLab Dedicated customers do not need to act.

Two other fixes in the same release deserve a line each, because they change the risk calculus for Enterprise Edition. CVE-2026-87719 (CVSS 9.9) is an insecure deserializationDeserialization🛡️The process of converting stored or transmitted data back into an object. Insecure deserialization can allow attackers to execute code by manipulating serialized data. issue in the GraphQL subscription serializer that lets an authenticated user with Duo Chat access pull Advanced Search instance configuration and its credentials. CVE-2026-88765 (CVSS 8.5) is a buffer overflowBuffer Overflow🛡️A vulnerability where a program writes data beyond the boundaries of allocated memory, potentially overwriting adjacent memory and allowing attackers to execute malicious code. in the Unicode conversion wrapper used by Advanced Search indexing, reachable by importing a crafted project export and rated as authenticated remote code execution. It affects EE all the way back to 12.3. Neither is in the KEV catalog, but both are on the same patched builds, so a single upgrade closes all three.

Technical Analysis

The failure here is two independent controls collapsing at once. The commits API endpoint accepted a file path that was not confined to the repository, and it did not enforce authentication on that code path. Either bug alone would be serious. Together they turn a read-only API into an unauthenticated file server for anything the GitLab application user can open. For a deeper walkthrough of the bug class, see How Path Traversal Bugs Let Attackers Read Files Outside the Web Root.

What makes a file read on GitLab a full-compromise event is what lives on disk. On Linux package installs, GitLab's backup documentation names two files that must be protected above all others: the main configuration at `/etc/gitlab/gitlab.rb` and the secrets file at `/etc/gitlab/gitlab-secrets.json`. The docs state that the secrets file contains the database encryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key. key, and that without it the application cannot decrypt any encrypted values in the database. The list of things protected by that key, per GitLab's own troubleshooting guide, includes CI/CD variables, runner authentication tokens, deploy tokens, webhooks, integrations, project mirroring credentials, and two-factor secrets. Field Effect's advisory lists the same categories of exposure: application secrets, authentication tokens, SSH keys, database credentials, cloud access keys, and configuration data. That is the whole CI/CD trust chain in one JSON file, which is the argument made in Why One File Read Can Compromise Your Entire CI/CD Platform.

There is one factual disagreement worth flagging. GitLab's advisory says exploitation works "under certain conditions" without naming them. watchTowr's Knott states the condition is the presence of at least one public project. Horizon3's write-up says there is no vendor-provided workaround and that restricting network access only reduces risk temporarily. Until GitLab publishes more detail, assume any internet-reachable instance with a public project is exploitable, and do not assume that a private-only instance is safe.

Immediate Actions

Patch first. Upgrade to 19.3.2, 19.2.6, or 19.1.8 depending on your track. Horizon3 and Field Effect both stress that there is no configuration workaround. To confirm what you are running, GitLab's API documentation describes `GET /api/v4/version`, which needs a private token in the request header and returns the version and revision.

Then hunt. watchTowr's detection guidance is to search for HTTP POST requests to URIs matching `/api/v4/projects/{id}/repository/commits/` that carry `file.path` parameters. GitLab's logging documentation places the API request log at `/var/log/gitlab/gitlab-rails/api_json.log` on Linux package installations and `/home/git/gitlab/log/api_json.log` on self-compiled ones. That log records method, path, params, remote_ip, status, and user_id per request, which is exactly the set of fields you need to distinguish a probe from a successful read. Any matching request from an unfamiliar source IP that returned a 200 should be escalated. Requests that predate 10 September deserve a closer look, since a HackerOne report does not guarantee no one else found the bug first.

If you find a hit, or you cannot rule one out because logs rotated, assume the secrets file was read. That means rotating everything it protects, which is a larger job than most teams expect. The site's guide How to Rotate Every Secret After a Server Compromise covers the general sequencing.

Reduce the precondition. If watchTowr's public-project requirement holds, an instance with no public projects has less exposure. GitLab's admin settings under Visibility and access controls include a restricted visibility levels option; restricting the Public level means only administrators can create public groups, projects, and snippets. The how-to How to Lock Down Public Projects on Self-Managed GitLab walks through that setting and the audit that should precede it. This is a compensating controlCompensating Control🛡️A security measure applied in place of a primary control that cannot be implemented yet, such as network restriction while a patch is unavailable. It reduces risk to an acceptable level without fixing the underlying flaw., not a fix, and it does nothing for instances that legitimately host public code.

Federal agencies have until 14 September under BOD 26-04. Everyone else should use the same clock. How to Triage a CISA KEVCISA KEV🛡️The Known Exploited Vulnerabilities catalog maintained by CISA, listing vulnerabilities actively exploited in attacks that federal agencies must patch by specific deadlines. Addition in 72 Hours lays out a workable sequence for a deadline this short.

Long-Term Outlook

This is the second critical GitLab bug in under a month to be exploited almost immediately. CVE-2026-19478, a CVSS 9.4 GraphQL flaw patched on 17 August that let unauthenticated attackers modify or delete public projects, was being probed by 19 August according to SecurityWeek's reporting on watchTowr's honeypot data. Knott drew the same comparison, noting that the August bug also saw almost immediate exploitation. The pattern is consistent with what the site has tracked across JFrog, N-able, and others this quarter: for internet-facing developer infrastructure, the patch-to-exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. window is now hours, and the bug bounty pipeline that finds these issues is racing scanners that can weaponize a description before most teams have read it.

The structural lesson is about what a source-control server holds. GitLab is not just a code host. It is a secrets store, a CI/CD orchestrator, and often an identity broker for deploy tokens and runner registration. A file-read bug on a service like that is a credential-theft bug with extra steps. Teams that treat their GitLab server as an internal developer tool rather than tier-zero infrastructure will keep being surprised by how much a single CVE can unlock.

Sources

• GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 — https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/
• CISA Known Exploited Vulnerabilities feed, catalog version 2026.09.11 — https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• NVD, CVE-2026-85706 — https://nvd.nist.gov/vuln/detail/CVE-2026-85706
• watchTowr, Rapid Reaction: GitLab Path Traversal VulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. (CVE-2026-85706) — https://watchtowr.com/resources/rapid-reaction-gitlab-critical-path-traversal-vulnerability-cve-2026-85706/
• Horizon3, CVE-2026-85706: GitLab Path Traversal — https://horizon3.ai/attack-research/vulnerabilities/cve-2026-85706/
• The Hacker News, GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure — https://thehackernews.com/2026/09/gitlab-cvss-10-file-read-flaw-draws-in.html
• SecurityWeek, GitLab Vulnerability Exploited One Day After Disclosure — https://www.securityweek.com/gitlab-vulnerability-exploited-one-day-after-disclosure/
• SecurityWeek, Critical GitLab Flaw Exploited Shortly After Disclosure (CVE-2026-19478) — https://www.securityweek.com/critical-gitlab-flaw-exploited-shortly-after-disclosure/
• BleepingComputer, GitLab urges users to patch max severity path traversal flaw — https://www.bleepingcomputer.com/news/security/gitlab-urges-users-to-patch-max-severity-path-traversal-flaw/
• Field Effect, GitLab fixes critical vulnerability as internet-wide probing begins — https://fieldeffect.com/blog/gitlab-fixes-critical-vulnerability-probing-begins
• GitLab docs: Back up GitLab (secrets file) — https://docs.gitlab.com/administration/backup_restore/backup_gitlab/
• GitLab docs: Troubleshooting backups, when the secrets file is lost — https://docs.gitlab.com/administration/backup_restore/troubleshooting_backup_gitlab/
• GitLab docs: Log system (api_json.log) — https://docs.gitlab.com/administration/logs/
• GitLab docs: Version API — https://docs.gitlab.com/api/version/
• GitLab docs: Visibility and access controls — https://docs.gitlab.com/administration/settings/visibility_and_access_controls/