GitLab CVSS 10.0 Path Traversal Flaw Hit by Active In-the-Wild Exploitation

GitLab has shipped emergency patches for a maximum-severity path traversal vulnerability—CVE-2026-85706 with a CVSS score of 10.0—that is already being probed by attackers in real time. The flaw resides in the repository commits API and stems from improper path confinement and missing authentication enforcement, allowing an unauthenticated attacker to read arbitrary files from a vulnerable GitLab server under specific conditions. Affected versions include all GitLab Community Edition (CE) and Enterprise Edition (EE) releases from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2.

Threat intelligence firm watchTowr reported active in-the-wild probing of the flaw beginning at 06:00 UTC on September 11, 2026—just hours after public disclosure. Attackers are leveraging the bug to read log files and GitLab-specific configuration files in order to harvest credentials, secrets, and other sensitive information. Patched in the same release wave is a second critical bug, CVE-2026-87719 (CVSS 9.9), an insecure deserialization flaw in GitLab EE that lets an authenticated user with Duo Chat access exfiltrate Advanced Search instance configurations and sensitive credentials via a crafted GraphQL subscription argument.

"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," said Jake Knott, head of threat intelligence at watchTowr. "Exploitation requires just one requirement: at least one public project must exist." Knott warned that mass exploitation is likely imminent, urging defenders to review log files for HTTP POST requests targeting '/api/v4/projects/{id}/repository/commits/' URIs containing 'file.Path' parameters to identify potential exploitation attempts. Organizations running self-hosted GitLab instances exposed to the internet should patch immediately or restrict public access where feasible.

Given the credential-exposure risk inherent in this class of file-read flaw, security teams should urgently audit any secrets stored on GitLab servers and rotate exposed tokens. Admins can verify whether their GitLab instance is properly secured externally by running a quick SSL/TLS checker and a port scanner to confirm no unintended services are exposed. Developers should also validate that none of their credentials appear in known leaks using a password checker before attackers pivot those harvested secrets into downstream attacks on CI/CD pipelines and source repositories.