Canadian Cyber Security Journal
SOCIAL:
Filed under: TechTalk

GitLab’s Maximum-Severity File-Read Flaw Is Already Under Attack

What Happened

GitLab disclosed CVE-2026-85706, a maximum-severity path traversal flaw in its repository commits API carrying a CVSS score of 10.0. The flaw combines two failures: the API does not confine requested file paths to the intended repository directory, and it does not enforce authentication on the affected function. Together, these let an unauthenticated attacker send a single request and read arbitrary files from the GitLab server, including SSH keys, database credentials, deploy tokens, and CI/CD variables. GitLab shipped fixes in versions 19.3.2, 19.2.6, and 19.1.8 on September 10. Exploitation began within 24 hours of disclosure, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 11 with a federal remediation deadline of September 14. Read the original coverage from The Hacker News.

Why This Matters for Canadian Organizations

Self-hosted GitLab runs inside a large share of Canadian software teams, government agencies, and universities keeping source code and CI/CD pipelines on infrastructure they control rather than a vendor’s cloud. A file-read flaw at this severity hands an attacker the keys to everything downstream of the repository: cloud credentials stored in CI/CD variables, deploy tokens for production systems, and SSH keys reused across other services. Because no authentication is required, exposure does not depend on weak passwords or stolen accounts, only on an internet-reachable GitLab instance running an unpatched version. Organizations subject to OSFI B-13 or handling regulated data face direct exposure if downstream credentials grant access to financial or customer systems.

What to Do

Patch self-hosted GitLab instances to 19.3.2, 19.2.6, or 19.1.8 immediately, and treat any instance left unpatched since September 10 as potentially compromised. Rotate CI/CD variables, deploy tokens, and SSH keys stored in affected repositories rather than assuming a patch alone closes the exposure, and review access logs for the repository commits API for requests outside normal developer activity.

Enjoy this article? Don’t forget to share.