GitLab Patches Maximum-Severity Path Traversal Flaw Under Active Probing
GitLab released emergency security updates addressing a maximum-severity path traversal vulnerability tracked as CVE-2026-85706 (CVSS 10.0). The flaw resides in the repository commits API endpoint (/api/v4/projects/:id/repository/commits/) and stems from improper path confinement combined with absent authentication enforcement on the file.path parameter. On self-managed GitLab Community and Enterprise Edition instances hosting at least one public repository, an unauthenticated remote attacker can exploit the endpoint via a single crafted HTTP request to traverse directory boundaries and read arbitrary files accessible to the git system user, including gitlab-secrets.json, database credentials, and CI/CD signing keys.
Discovered by researcher s3ntago via HackerOne, the vulnerability affects GitLab versions 18.7 through 19.1.7, 19.2 through 19.2.5, and 19.3 through 19.3.1. Following disclosure, threat intelligence firm watchTowr and perimeter honeypots observed automated scanning and opportunistic exploitation probes targeting internet-facing GitLab deployments. GitLab resolved the issue across backported releases 19.3.2, 19.2.6, and 19.1.8, noting that GitLab.com and multi-tenant dedicated infrastructure were patched prior to public notification.
Why it matters:
- Unauthenticated secrets exfiltration: Because the repository commits endpoint completely omits authentication checks, remote actors can extract
gitlab-secrets.jsonand database credentials in a single HTTP request, bypassing perimeter defenses to forge administrator session tokens and compromise private codebase assets. - Immediate patching and access-log inspection: Administrators must upgrade self-managed deployments to patched releases immediately and audit web server logs for HTTP requests to
/api/v4/projects/*/repository/commits/containing traversal sequences in thefile.pathparameter to detect active probing or pre-patch data compromise.