Hours after GitLab shipped a CVSS 10.0 advisory, scanners were already hitting the repository commits API. The requests resembled a developer client asking for a commit. CVE-2026-85706 is a path traversal flaw that lets anyone, with no login, read arbitrary files from the GitLab server. If your cybersecurity program still files source-control under “dev tools,” that classification just failed in public.

The patch note arrived after the probes

GitLab published fixes for several issues this week. The one that matters scored a perfect 10.0. The Hacker News and SecurityWeek tracked the same ugly clock. Public disclosure on day one. Probes in the wild within hours. Working exploitation by the next day. You do not get a change-advisory-board meeting inside that window.

The bug lives in the repository commits API. Path traversal on that endpoint is enough for an unauthenticated caller to pull files from the GitLab host. That box runs your merge requests, CI triggers, and deploy keys. A successful read is a shot at whatever the GitLab process can open. Configuration. Secrets files. Runner tokens. SMTP passwords. Object-storage keys. SSH material. Backup credentials sitting in the same directory tree because someone treated the app server as a filing cabinet.

Self-managed GitLab on the public internet is the exposed case. So is the Community Edition VM a team stood up for a hackathon and never tore down. GitLab.com is GitLab’s patch problem. Your problem is every instance you can still find in certificate logs, old asset inventories, or a leftover DNS name. If that instance was reachable when the advisory landed, assume someone asked it for files. A runner registration token pulled off disk turns a source-control bug into fleet execution the same afternoon.

Your cybersecurity stack saw a valid API call

Most perimeter kits are still waiting for a story they already know. A brute-force spray against the sign-in page. A noisy scanner bouncing off the firewall. A threat-protection signature for a packaged exploit. CVE-2026-85706 shows up as an HTTP request to an API your developers use every hour. Status 200. No failed logins. No lockout. Threat detection that only lights up on authentication failures will file this under noise, if it files it at all.

Defense in depth that starts at the login form has a hole the size of every unauthenticated route. GitLab has plenty of those by design, because public projects and clone traffic are features. The commits API is supposed to answer. The traversal is what turns that answer into a file server. Your WAF might catch crude parent-directory sequences. Plenty of encodings slip past rules written for last decade’s PHP apps. Do not bet the tenant on a regex.

You are watching the same harvesting reflex around other poorly locked developer gateways. A SANS Internet Storm Center diary this week described an attacker using a semi-autonomous coding agent to find LLM resale frontends, grab API access through ordinary web flaws and account farming, validate the stolen inference capacity, then aggregate it behind one gateway. Different product. Same loop. If an internet API hands out privilege without a hard identity check, someone will wrap it in a script. GitLab’s loop reads files. The LLM loop resells compute. Both jobs keep running over the weekend.

Assume a secrets dump, then shrink the surface

Patch every self-managed GitLab instance to the versions GitLab shipped for this advisory. If you cannot patch in the next few hours, pull the instance off the internet and put it behind SSO plus a network allowlist. Internet-wide GitLab is a choice. Treat it like one.

Then run incident response as if the files left the building. Rotate the secrets that live on a typical GitLab host: the Rails secret, database password, SMTP credentials, object-storage keys, runner tokens, deploy keys, and any CI variables stored on disk or in backups on that box. Revoke and reissue. A patched host that still holds last week’s secret file is a patched host that still belongs to whoever read it.

Pull access logs for the commits API around the disclosure window. Look for odd paths, encoded dots, unexpected project IDs, and callers you do not recognize. You may not get a clean indicator. If the instance was public, rotate anyway. Absence of a pretty alert is not evidence of safety.

Ongoing security hardening starts with inventory. Keep a living list of every GitLab and leftover SCM box, including the forgotten Community Edition on a spare VM. Give cyber security the same ownership of those hosts that you already give domain controllers. They mint credentials. They store them. They sit on the deploy path.

Put authentication in front of management and API listeners even when some projects are public. Allowlist the admin UI. Stop parking extra cloud keys in the GitLab config “just in case.” Tune detection for API paths and file-read shapes. A brute-force control will never fire on an unauthenticated traversal. Build the alert for the request, then keep the host off the open internet unless you have a real reason it belongs there.

Sources

• GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure
• GitLab Vulnerability Exploited One Day After Disclosure
• The Self-Expanding Stolen Inference Supply Chain: An AI Agent Harvesting and Re-Serving LLM Access