Topic starter
14/09/2026 10:10 am
TL;DR: A CVSS 10.0 path traversal flaw in GitLab CE and EE lets anonymous attackers read arbitrary files through the repository commits API, and Ethiack says it is already detecting exposure across affected self-managed instances. The risk is not just file disclosure, because reachable GitLab servers often sit at the centre of CI/CD trust, making exposed secrets and tokens an immediate governance problem.
Editorial analysis by NHI Mgmt Group, based on content published by Ethiack: “Now Detecting: CVE-2026-85706 - Unauthenticated Arbitrary File Read in GitLab”.
Key questions
Q: What should teams do after a GitLab file-read vulnerability is discovered?
A: Treat the incident as both a platform compromise and a secret-exposure event.
Q: Why is unauthenticated file read in GitLab a credential-governance issue?
A: Because GitLab often stores the secrets that power pipelines, runners, deploys, and database access.
Q: What are the signs that a source control platform flaw has become an identity incident?
A: Look for exposed CI/CD variables, unexpected token use, unknown runner registrations, and any file access paths that could reveal credentials stored in configuration or environment files.
Practitioner guidance
- Patch all affected GitLab instances immediately Upgrade self-managed GitLab CE or EE to 19.3.2, 19.2.6, or 19.1.8, and plan for database migrations and possible downtime during the change window.
- Reduce reachability until patching is complete Place unpatched instances behind SSO, a VPN, or an IP allowlist, and restrict /api/v4/projects/*/repository/commits* at the WAF or reverse proxy.
- Rotate every exposed machine credential If the instance was exposed while unpatched, rotate secret_key_base, database credentials, CI/CD variables, runner registration tokens, access tokens, and deploy keys.
Bottom line: This flaw turns GitLab from a code-management issue into a machine-identity exposure point because the platform often stores secrets that downstream systems trust.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:11 am
Arbitrary file read in a control-plane application is an identity problem, not just a web vulnerability. When a source control platform stores CI/CD secrets and deployment credentials, anonymous file access becomes machine-identity exposure. That changes the response model from patching a bug to protecting the non-human identities that inherit trust from the platform. Practitioners should treat the credential estate behind GitLab as part of the incident surface, not a separate cleanup task.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should security teams compare patching to credential rotation after a GitLab vulnerability?
A: Use both, but sequence them according to exposure. Patching removes the exploit path, while rotation removes any trust the attacker may have harvested before the fix. If the instance was reachable while unpatched, rotation should follow immediately after containment and before routine service resumption.
👉 Read our full editorial: CVE-2026-85706 exposes GitLab files through unauthenticated API access