GPU VulnDB

Database/Control plane, storage & DevOps

GitLab: unauthenticated arbitrary file read via the repository commits API

CVSS 10.0CVE-2026-85706Control plane, storage & DevOpsKnown exploitedcurated

Impact

An unauthenticated caller can read arbitrary files from the GitLab server through improper path confinement plus missing authentication enforcement in the repository commits API. On a fleet where GitLab is the CI/CD and GitOps source of truth, that means secrets files, deploy tokens, runner registration tokens, SSH host and deploy keys, and database credentials on the application node are readable by anyone who can reach the web port. Anything harvested this way is a path into the cluster the runners deploy to, so the blast radius is not limited to source code. CISA lists this as known-exploited, and the CVSS scope change to 10.0 reflects that the disclosure crosses into other systems.

Who can reach it

Anyone who can reach the GitLab HTTP endpoint. No authentication and no user interaction required - internet-exposed self-managed instances are directly reachable.

What to do

Upgrade to GitLab 19.1.8, 19.2.6 or 19.3.2 (versions from 18.7 onward are affected) and restart the application; this is a service restart on the GitLab node, not a fleet-wide action. Because the flaw is in the KEV catalogue, treat any pre-patch instance as potentially read: rotate runner registration tokens, deploy keys, CI variables and any credentials stored in files on the GitLab host after upgrading, and review access logs for anomalous commits-API requests.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.