A file.path parameter in GitLab's commit API reads server files before authentication

The traversal string travels in the request body. GitLab's commit API accepts a `file.path` parameter, and the attack supplies a path outside the intended scope; when the conditions are met, the server returns file contents ^[3]. A default reverse-proxy access log records the method, the URL and the status, and the body goes unlogged. The write-up says so in its own detection notes: URLs alone cannot verify the `file.path` value, so you need a proxy or application log that captures request bodies ^[9]. Most self-managed instances leave bodies out, for the sensible reason that bodies contain secrets.

That leaves a weaker signal. The same guidance suggests checking response sizes on unauthenticated requests and the traffic that follows, while conceding that a large response by itself falls short of confirming that file data left the box ^[10]. On a host that keeps no file-access records, the write-up says past reads may never be pinned down after the fact ^[11].

Patching and rotating are two separate decisions. Updating to 19.3.2, 19.2.6 or 19.1.8, or later in each series, prevents reads caused by this flaw ^[4]. A token already copied is untouched by the update. The write-up lists GitLab guidance titled "Rotate the secrets file" among its related sources ^[12], and notes separately that revoking credentials is a countermeasure distinct from tightening file permissions and narrowing where sensitive data is stored ^[13].

Those three fixed versions cover the 19.1, 19.2 and 19.3 series ^[16]. Anyone running an older series sits outside that list. The same write-up lists a second CVE, CVE-2026-87719, alongside CVE-2026-85706 ^[15].

What public reporting confirms is scanning. The dev.to write-up, dated 11 September 2026 and citing BleepingComputer and GitLab, says attack attempts were observed the day after disclosure ^[6][5]. It also says that on the published reconnaissance information, success as far as obtaining valid credentials and unauthorized access has not been confirmed ^[7]. A good deal of the rest of its guidance is labelled inference by the author, including the VPN and allowlist advice ^[14] and the list of what a stolen token would reach: repositories, CI/CD variables, artifacts and runners ^[17]. That labelling is unusual and useful.

The flaw itself is rated CVSS 10.0 against self-managed GitLab CE and EE, on the grounds that an unauthenticated network caller can read credentials and sensitive information ^[1][2][20]. The interface shows nothing of the request, and the attack runs without user interaction, so normal use of the instance will not surface it ^[8].

In my view, an instance that was internet-facing during the exposure window, with no body-capturing proxy logs and no host file-access records, should rotate the secrets file and the credentials stored near it. The write-up's follow-up checks all run after the fact: token use from unknown sources, runner registration, project enumeration ^[18].