Security Digest · Sep 10, 2026 · Vulnerability · CI/CD
GitLab CVE-2026-85706: Unauthenticated File Read, Exploited
CVSS 10 path traversal in GitLab's commits API lets anyone read server files, including secrets. Fixed in 19.3.2/19.2.6/19.1.8. In CISA KEV. Patch now.
Our verdict
Act now
Any unpatched self-managed GitLab 18.7 or later can have its configuration and secret keys read by anyone on the network, and CISA says it is being exploited; upgrade today and rotate secrets if you were exposed.
Who must act: Administrators of self-managed GitLab CE/EE 18.7 and later (Omnibus, source, Helm), above all instances reachable from the internet.
Who can relax: GitLab.com and GitLab Dedicated customers (GitLab patched those), and self-managed instances still on versions before 18.7, which are outside the affected range.
- Affected
- GitLab CE/EE 18.7 through 18.11.x before 18.11.12
GitLab CE/EE 19.0.x before 19.0.9
GitLab CE/EE 19.1.x before 19.1.8
GitLab CE/EE 19.2.x before 19.2.6
GitLab CE/EE 19.3.x before 19.3.2 - Fixed in
- GitLab 19.3.2
GitLab 19.2.6
GitLab 19.1.8
GitLab 19.0.9 (backport, Sep 23, 2026)
GitLab 18.11.12 (backport, Sep 23, 2026) - CVSS
- 10.0 (v3.1, vendor)
- EPSS
- 92.0% (percentile 99.8)
- CISA KEV
- Yes, listed as known exploited
- Exploitation
- Exploited in the wild
- Severity
- Critical
What to do
- Check your version (Admin > Overview, or /help) and upgrade to 19.3.2, 19.2.6, 19.1.8, 19.0.9 or 18.11.12 or later.
- If you cannot upgrade immediately, remove internet exposure of the instance until you can.
- Search api_json.log for unauthenticated POSTs to repository commits or files APIs carrying a file.path parameter.
- If an exposed instance ran a vulnerable version, rotate gitlab-secrets.json / secrets.yml material, database, object storage, SMTP and LDAP credentials, and CI/CD secrets.
- Deploy GitLab's published LFI detections in your SIEM.
How to check if you are affected or compromised
- In api_json.log, look for POST /api/v4/projects/:id/repository/commits requests with no meta.user whose params include file.path pointing at host paths such as gitlab.yml, secrets.yml, database.yml or gitlab-secrets.json.
- Look for percent-encoded or trailing-slash variants of the commits and files API routes from unfamiliar IPs.
- Use GitLab's three published detections: LFI reading gitlab.yml, LFI via metadata.path, and LFI file path attempt.
- After a suspected read, watch for sessions or tokens you did not issue and unusual access to object storage or the database.
What happened#
On September 10, 2026 GitLab shipped a critical patch release (19.3.2, 19.2.6, 19.1.8) whose top fix is CVE-2026-85706. The bug is a path traversal in the repository commits API. GitLab's description: "an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement." GitLab scores it CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). A HackerOne researcher, s3ntago, reported it.
CISA added it to the KEV catalog on September 11, one day after the patch, with a federal due date of September 14. CISA's enrichment in the CVE record marks exploitation as active and the attack as automatable. On September 23 GitLab backported the fix to 19.0.9 and 18.11.12.
GitLab's security team published detection notes describing the mechanism. On multipart uploads, Workhorse passes Rails a file.path parameter. An attacker sends an empty file part with a file.path that points at a file on the server, so Rails reads that host file instead of uploaded bytes. The notes say the parameter is reached mainly through POST /api/v4/projects/:id/repository/commits and the repository files API. They add that "public exploits defeat route sanitization with a trailing-slash bypass and percent-encoding."
Who is affected#
Self-managed GitLab CE and EE from 18.7 onward is affected, covering every deployment type: Omnibus, source and Helm. Vulnerable ranges are 18.7 to before 18.11.12, 19.0 to before 19.0.9, 19.1 to before 19.1.8, 19.2 to before 19.2.6, and 19.3 to before 19.3.2. GitLab.com and GitLab Dedicated were already patched, so customers there have nothing to do.
Do you really need to act?#
Yes, if you run GitLab yourself on an affected version. This is about as bad as a "file read" gets:
- No authentication is needed. CISA rates it automatable and confirms exploitation.
- The prime targets are
gitlab.yml,secrets.yml,database.ymlandgitlab-secrets.json. GitLab's own detection notes say these hold the Rails secret key base and the encryption keys used for sessions, tokens, stored CI/CD variables and 2FA, plus database, object storage, SMTP and LDAP credentials. "A confirmed read is therefore a credential exposure, not merely an information disclosure." - With the secret key base, an attacker can forge sessions and decrypt CI/CD variables. That reaches your cloud accounts and deployment pipelines.
Instances only reachable on a private network carry less risk but should still be patched promptly. Versions before 18.7 are not in the affected range.
What to do now#
- Check the version (
sudo gitlab-rake gitlab:env:infoon Omnibus, or the Help page) and upgrade to 19.3.2, 19.2.6, 19.1.8, 19.0.9 or 18.11.12 or later (sudo apt-get install gitlab-ee=<version>or your Helm chart bump). - If you can't upgrade today, take the instance off the internet until you can.
- Hunt in
api_json.logas described below. - If an internet-exposed instance ran a vulnerable version after September 10, plan for secret rotation: regenerate secrets in
gitlab-secrets.jsonfollowing GitLab's procedures, rotate database, object-storage, SMTP and LDAP credentials, rotate CI/CD variables that hold cloud or deploy keys, and invalidate active sessions and tokens.
How to tell if you were hit#
GitLab's detections look in api_json.log for unauthenticated requests (an ip/<addr> client with no meta.user) to the commits or files APIs whose params contain an empty file part and a file.path pointing at config or secret files. GitLab published three rules: "GitLab LFI attempt reading gitlab.yml", "GitLab LFI via metadata.path parameter" and "GitLab LFI file path attempt". Widen your search to other host paths such as /etc/passwd, /proc/self/, SSH keys and .env files. Rejected attempts (status 400) are still worth logging. A successful response to such a request means you should rotate secrets. Afterwards, watch for unfamiliar sessions, new personal access tokens and odd access to object storage or the database.
Timeline#
- — GitLab releases 19.3.2, 19.2.6 and 19.1.8 with the fix.
- — CISA adds CVE-2026-85706 to KEV, with a federal due date of Sep 14.
- — The CVE record is published (NVD).
- — GitLab backports the fix to 19.0.9 and 18.11.12.
Vulnerability records
- CVE-2026-85706 · KEV 2026-09-11 · GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6…
Sources
Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.