GitLab released a patch for CVE-2026-85706 on September 10. By 06:00 UTC on September 11, watchTowr's honeypot network was already seeing probes against the flaw in the wild. CISA added it to the Known Exploited Vulnerabilities catalog that same day and told federal agencies to patch by September 14.
If you're reading this on September 15, that deadline is yesterday.
The vulnerability gets a CVSS score of 10.0 — the maximum. The exploit is a single unauthenticated HTTP request. The attacker doesn't need credentials. They don't need to be a registered user. They send one request to your GitLab API and read arbitrary files from your server.
This is the kind of vulnerability that turns self-hosted infrastructure from an asset into a liability in an afternoon.
What the exploit actually does
The path traversal flaw sits in GitLab's repository commits API. The specific problem is "improper path confinement and missing authentication enforcement" — which, in plain English, means the API will read files outside the directories it's supposed to be restricted to, and it won't check whether you're logged in first.
An attacker sends an HTTP POST to /api/v4/projects/{id}/repository/commits/ with a crafted file.path parameter. The server returns the file contents. That's it.
What files are on a GitLab server? Configuration files with database connection strings. Secret keys for your CI/CD pipelines. OAuth tokens for third-party integrations. SSH keys. .env files committed to repositories by someone who forgot to add them to .gitignore. Cloud provider credentials cached by a runner that connected to AWS or Azure during a build.
If your GitLab instance can reach your production environment — and most CI/CD setups have exactly that access — then whoever reads those config files can likely reach your production environment too.
watchTowr's rapid reaction report describes attackers first using the bug to read local configuration data, confirm the environment, and then escalate from there. The initial read is reconnaissance. What comes next depends on what they found.
Who's at risk
The affected versions are GitLab Community Edition and Enterprise Edition from 18.7 up to (but not including) 19.1.8, 19.2.6, and 19.3.2. If you're running a self-hosted GitLab instance and haven't patched in the last five days, you're almost certainly in that range.
GitLab.com and GitLab Dedicated (the cloud-managed options) are already patched and not vulnerable. This is a self-hosted problem.
And there are a lot of self-hosted GitLab instances. Public sector orgs run it because they want source code sovereignty. NGOs run it because they need an audit trail on their repositories and don't want a vendor holding all their code. Small engineering teams run it because the on-premise option gave them more control than GitHub. That's exactly the kind of organization that often has fewer IT resources to catch and respond to a CVE like this quickly.
The supply chain angle
Dark Reading flagged this as a supply chain risk, and that framing is worth unpacking.
Your GitLab instance isn't just a place to store code. It's the system that builds, tests, and deploys your code. If an attacker reads your runner credentials or CI/CD secrets, they're not just reading files — they're potentially positioning themselves to insert malicious code into your build pipeline or deploy something into your production environment without touching your codebase directly.
For a 20-person nonprofit with a GitLab instance managing their donor portal or case management system, that's not a theoretical risk. It's a very concrete path from "unauthenticated HTTP request" to "production data compromised."
Check whether you've already been hit
Defenders should hunt through log files for HTTP POST requests to URLs matching the pattern /api/v4/projects/{id}/repository/commits/ containing file.path parameters with unexpected values — anything that looks like a path walking up directory levels. This is the fingerprint of an exploit attempt.
If you see those requests in your logs, you need to treat the instance as potentially compromised, rotate every credential and secret that was accessible from that server, and check your CI/CD pipeline integrity.
What to do right now
Patch first. Upgrade to GitLab 19.1.8, 19.2.6, or 19.3.2, depending on which release train you're on. This is not a "schedule it for next week" situation — active exploitation has been running for four days.
Inventory what your GitLab instance can reach. CI/CD runners that have access to production credentials, cloud API keys, or database connection strings should have those credentials rotated immediately after patching, even if you see no sign of compromise. Assume the worst; rotate anyway.
Audit your .gitignore and repository history. If anyone ever committed secrets to a repo your GitLab hosted, those files are potentially readable through this flaw even if they were deleted later — file deletion doesn't scrub git history. That's a separate cleanup problem.
Check your logs for the exploit pattern. Even if you patch now, someone may have already read those files before you did. The log check tells you whether you're patching a vulnerability or responding to an incident.
If you're running an old or unmaintained GitLab instance: take it off the public internet temporarily if patching isn't immediately possible. An unpatched GitLab instance with internet exposure is a liability that should be isolated until it can be fixed.
The broader pattern
The patch-to-exploit window on this one was effectively zero. WatchTowr had honeypot hits the morning the patch landed. That's a pattern we're seeing more often: a CVE goes public, researchers and attackers alike reverse-engineer it within hours, and if you're running an automated patch process that runs weekly, you're already behind.
For small organizations running self-hosted infrastructure, the lesson isn't to go back to cloud-managed tools (though that's worth reconsidering for non-critical systems). It's to treat patching as a continuous process — not a quarterly IT task — especially for internet-exposed systems that hold credentials.
We help small teams audit their self-hosted infrastructure, identify what's exposed, and build patch processes that run faster than attackers can reverse-engineer disclosures. If that's a conversation worth having, reach out.
Patch GitLab first. Then come find us.