One HTTP Request Away From Everything

On September 10, GitLab shipped an emergency patch for CVE-2026-85706 — a path traversal vulnerability in its repository commits API that earned the maximum possible severity score: CVSS 10.0. Within hours of disclosure, security firm watchTowr confirmed that attackers were already probing exposed servers in the wild. By September 11, CISA had added it to the Known Exploited Vulnerabilities catalog.

The technical details are worth stating plainly. A single unauthenticated HTTP request to a self-managed GitLab server could read any file on the system. No credentials required. No social engineering. No sophisticated exploit chain. One request. Every file.

If you are an executive or a board member, that sentence should land differently than it does for the engineers in the room. Because the question is not whether your GitLab server has source code on it. The question is what else is stored there — and whether anyone in your organization has inventoried what a complete read of that filesystem would expose.

Your Source Code Platform Is a Vault — Treat It Like One

Most executives think of GitLab or GitHub as "where the developers work." That framing misses the risk entirely. A self-managed GitLab instance is a vault. It holds your source code, yes. But it also holds SSH keys, database credentials, cloud access tokens, deploy configurations, API secrets, CI/CD pipeline definitions, and — in many organizations — internal documentation, architecture diagrams, and customer data embedded in test environments.

Security researchers estimate that more than 20,000 self-managed GitLab instances sit exposed on the public internet right now. Every one of them running an unpatched version before September 10 was an open vault with no lock on the door.

This is the second critical GitLab vulnerability in less than a month. In August, CVE-2026-19478 — rated CVSS 9.4 — allowed unauthenticated attackers to delete or rewrite public projects on self-managed servers. Two maximum-severity vulnerabilities in the same platform within weeks is not a coincidence. It is a pattern. And patterns demand a different conversation than one-off incidents.

The Speed Gap the Board Needs to Understand

Here is the timeline that matters. GitLab released the patch on September 10. By 06:00 UTC on September 11 — less than twenty-four hours later — watchTowr confirmed active exploitation probes in the wild. CISA added it to the KEV catalog the same day.

In Cyber Risk Is Business Risk, I describe this as the speed asymmetry — the structural gap between how fast attackers weaponize a vulnerability and how fast defenders can patch it. That gap has been compressing for years. AI-powered vulnerability scanning is accelerating it further. But even without AI, the GitLab timeline tells the story: less than a day from patch to exploitation probes. Your patching window is no longer measured in weeks or even days. It is measured in hours.

The board-level question is not "Did we patch it?" It is "How long were we exposed, and do we know what was accessed during that window?" If your security team cannot answer both halves of that question, your incident response capability has a gap that no compliance checkbox will close.

The Three Questions, Applied

I built the Three Questions framework for exactly this kind of moment — when a vulnerability makes headlines and the instinct is to ask "Are we affected?" That is the wrong first question. The right sequence is:

What are we protecting? Not "GitLab" in the abstract. Specifically: what data, credentials, intellectual property, and access tokens live on your self-managed GitLab instance? Has anyone ever inventoried the secrets stored in CI/CD variables, repository files, and server configuration? In most organizations, the honest answer is no — and that means no one knows the blast radius of a compromise.

How well are we protecting it? If your GitLab server is reachable from the public internet — and more than 20,000 are — you have already answered this question, and the answer is not good enough. But even behind a VPN, the absence of authentication on this API endpoint means that any compromised internal account, any lateral movement from a phished employee, gives an attacker the same one-request access to everything. Defense in depth is not optional for platforms that hold your crown jewels.

What happens if we fail? A complete filesystem read on a GitLab server is not a data breach in the traditional sense — no customer records may be involved. But it is potentially worse. Stolen source code enables future attacks. Harvested credentials unlock cloud infrastructure, databases, and production systems. Exfiltrated CI/CD configurations reveal your entire deployment pipeline. The downstream exposure from a developer platform compromise can dwarf the initial incident by orders of magnitude.

What to Ask Your CISO This Week

If this story prompts one conversation in your organization, make it this one:

First, ask whether your developer platforms — GitLab, GitHub, Bitbucket, Jenkins, whatever your teams use — are exposed to the public internet. If they are, ask why, and ask what the plan is to change that. Internet-facing developer infrastructure is a risk that most organizations accept by default rather than by decision.

Second, ask about secrets management. Are credentials, API keys, and access tokens stored directly in repositories or CI/CD variables? Or does your organization use a dedicated secrets vault with rotation policies? The GitLab vulnerability did not just expose source code. It exposed every secret that developers stored alongside it.

Third, ask about your patching timeline for developer tools specifically. Many organizations have rigorous patching programs for production systems but treat internal development infrastructure as a lower priority. This vulnerability is proof that attackers do not share that prioritization.

The Bigger Picture

This is not just a GitLab story. It is a pattern repeating across every category of enterprise software. In the same week, MikroTik patched six RouterOS vulnerabilities — two of which could be chained to take full control of routers without authentication, with over 122,000 devices exposed and active exploitation confirmed since early September. cPanel disclosed a SQL injection flaw that could give a single hosting account root-level control of an entire server. The N-able N-central remote monitoring platform shipped an emergency patch for a pre-authenticated remote code execution flaw.

The common thread: critical infrastructure software, exposed to the internet, exploited within days or hours of disclosure. The velocity of exploitation is outpacing the velocity of defense. That is a governance problem, not just a technical one.

Boards that treat cybersecurity as an IT concern are governing with a blind spot that regulators, insurers, and shareholders are increasingly unwilling to tolerate. The EU Cyber Resilience Act's mandatory vulnerability reporting obligations went live on September 11 — the same day attackers began probing this GitLab flaw. CISA is finalizing CIRCIA's 72-hour incident reporting rule this month. The regulatory walls are closing in because the threat environment demands it.

One HTTP request. Every file on the server. That is the risk your developers live with when the tools they rely on are not treated as critical infrastructure. The question is whether your board knows it.