Attackers are already probing for a maximum-severity GitLab vulnerability just one day after it was publicly disclosed and added to CISA’s KEV Catalog.
The flaw, tracked as CVE-2026-85706, carries a CVSS score of 10.0 and affects both GitLab Community Edition and Enterprise Edition. It allows an unauthenticated attacker, under certain conditions, to read arbitrary files from a vulnerable GitLab server.
The vulnerability is a path traversal issue in GitLab’s repository commits API caused by improper path confinement and missing authentication enforcement. Security researchers at watchTowr reported seeing in-the-wild probing beginning on September 11, within hours of disclosure.
GitLab patched the flaw in versions 19.1.8, 19.2.6 and 19.3.2 and is urging customers to upgrade immediately.
Denis Calderone, CTO, Suzu Labs:
“This is a big problem if you have an internet exposed GitLab instance. It takes just one request to pull gitlab-secrets.json gives an attacker the secret_key_base, and from there it’s session forgery, admin access, and full remote code execution on the box. We’re talking about a complete compromise path for the system that builds and ships your software.
“This patch came out September 10, watchTowr’s honeypots picked up active probing by 06:00 UTC on September 11, and multiple working proof-of-concept exploits hit GitHub the same day. CISA added it to the KEV catalog and gave federal agencies until today to patch. There are over 20,000 self-managed GitLab instances sitting on the public internet right now, and the only thing needed for exploitation is that a public project has to exist on the instance, which is extremely common.
“Obviously, if you have a self-hosted GitLab instance, get it patched, but if your GitLab instance was exposed to the Internet before September 10, you need to assume someone already tried this and hunt for IOCs. The detection signature is simple enough and you just need to look for HTTP POST requests to the repository commits API containing a file.path parameter. Legitimate use of that endpoint doesn’t include that parameter, so any hit is almost certainly an exploitation attempt. If you find one, rotate everything that server had access to. Everything is at risk including SSH keys, database credentials, deploy tokens, CI/CD variables, runner registration tokens. And if your self-managed GitLab doesn’t actually need to be internet-facing, this is as good a reason as any to pull it behind a VPN.”
Eric Capuano, Director of SOC Operations, Black Hills Information Security:
“The probing versus exploitation distinction does not mean much on this one. CVE-2026-85706 is a single unauthenticated HTTP request that returns the contents of a file. There is no payload, no staging, no second stage to wait for. Whoever is sending requests to find vulnerable servers is reading files with the same request they use to find them. Your exposure window opened on September 10 when GitLab shipped 19.1.8, 19.2.6 and 19.3.2, not on September 11 when someone noticed the traffic.
“What makes this worse than a typical file read is where it lands. A self-managed GitLab server holds gitlab-secrets.json, database and Redis credentials, CI/CD variables, runner registration tokens, deploy keys and personal access tokens. Reading files as the GitLab process is a credential harvest, and an upgrade does not un-steal a credential. The follow-on activity will not touch GitLab at all. It will be valid tokens authenticating to your registry and your build infrastructure, and it will look like normal pipeline traffic.
“Detection here is thin and teams should know that going in. A file read spawns no process, so EDR has nothing to show you. Your only record is the web tier. watchTowr’s hunting guidance is specific and worth taking: look for POST requests to /api/v4/projects/{id}/repository/commits/ carrying file.path parameters, and for unauthenticated requests to the commits API generally. If your logs have already rolled past September 10, you cannot prove you were not read, and you should work from the assumption that you were.
“Order of operations. Get an accurate version for every self-managed instance, including the one a product team stood up without telling anyone, and upgrade. The patch carries database migrations and takes single-node installs down, and that change window is the actual reason these boxes sit unpatched for weeks, so pull the instance off the internet until you can absorb the outage. Then rotate. Rotating GitLab’s own secrets file is ugly, because it breaks encrypted CI variables and 2FA seeds, which is exactly why people skip it and why you should not. CISA added this to KEV on the eleventh with a three day deadline and a forensic triage requirement attached, and triage is the half that gets dropped.”
Ryan McCurdy, VP of Marketing, Liquibase:
“The fact that attackers were probing for this vulnerability within hours of disclosure shows how little time organizations now have to respond to a critical CVE.
“Finding the vulnerability and releasing a patch are only the first steps. Enterprises still have to know whether they’re affected, understand the risk, test the fix, and get it into production without breaking something else. When exploitation starts almost immediately, slow or unclear remediation processes become part of the risk.
“That makes the response path just as important as the vulnerability itself. Organizations need to know who is accountable when a critical CVE is discovered, how quickly they can get a supported fix, and how they’ll safely deploy it across the systems that depend on that software.
“The question isn’t whether the software you depend on will ever have a vulnerability. It’s how prepared you are when the next critical one is discovered.”
John Strand, Owner, Black Hills Information Security, Inc.:
“This GitLab vulnerability, and a number of other vulnerabilities like it, don’t concern me all that much when we’re talking about enterprise teams that have good security awareness and solid patching processes.
“What concerns me are all the smaller, fly-by-night development shops standing up their own Git instances that simply aren’t plugged into security news. They aren’t following the alerts. They aren’t watching for the latest vulnerabilities.
“And that’s a question the security community has been wrestling with since its inception. How do we reach those people?
“There’s so much preaching to the choir. There’s this massive infosec echo chamber, while so much of the actual damage from these vulnerabilities happens to organizations that aren’t plugged in and aren’t getting security updates on a regular basis.
“For everything we’re seeing with CISA and all the different alerts being published, that’s great. I think the heart is in the right place. But it still doesn’t answer the bigger question.
“How do we reach the people who aren’t listening in the first place?”
I have said it before. Threat actors will quickly exploit any unpatched or patched vulnerability. Thus while you need to patch all the things, you also need to do continuous scans to make sure the bad guys never get in.
GitLab exploit leaves no traversal string says Black Hills Information Systems
Posted in Commentary with tags Black Hills Information Systems on September 15, 2026 by itnerdBlack Hills Information Security has just published new research, “The GitLab Exploit With No Traversal In It,” showing that detection guidance circulating for the recently exploited GitLab vulnerability, CVE-2026-85706, may send security teams looking for the wrong indicators.
The critical vulnerability allows unauthenticated attackers to read arbitrary files from affected GitLab servers under certain conditions. CISA lists it as exploited in the wild, making the question of how to detect exploitation immediately relevant.
Black Hills’ Active SOC team examined nginx and Rails logs and tested Sigma and Suricata detection rules. Its research challenges reliance on commits-endpoint monitoring alone and gives security teams practical guidance for investigating suspicious activity. The testing described in “The GitLab Exploit With No Traversal In It” is controlled validation, it’s not a count of attacks observed against customers.
Eric Capuano, Black Hills Information Security’s Director of SOC Operations, notes that for enterprises, the concern extends beyond the initial file read: exposed credentials or secrets could enable further compromise. Patches are available in GitLab versions 19.1.8, 19.2.6, and 19.3.2. Updating closes the vulnerability, but does not establish whether sensitive information was accessed beforehand.
Leave a comment »