Threat watchdog Shadowserver posted on Bluesky Nov. 1 that it was tracking more than 1,000 instances of a vulnerable GitLab integer overflow flaw, a bug that the Cybersecurity and Infrastructure Security Agency (CISA) on Friday added to its known exploited vulnerabilities (KEV) catalog.
Security pros said they were concerned because GitLab patched the maximum-severity bug on Oct. 12, so given that GitLab servers are typically self-managed, at least 1,000 servers were still at risk to a bug that was now confirmed exploited in the wild.
The 10.0 flaw – CVE-2026-97229 – lets an unauthenticated user execute arbitrary code on the GitLab server via a specially-crafted regular expression in a CI/CD configuration because of an insufficient regular expression validation.
Shane Barney, chief information security officer at Keeper Security, said the fact that more than 1,000 internet-exposed GitLab servers remain unpatched weeks after a critical fix was released exposes a harsh reality: reactive patching cycles have failed to protect modern development environments.
Barney said CI/CD pipelines and source code repositories are the engine of modern software delivery, making unpatched build infrastructure a prime entry point for supply chain attacks. Once an adversary compromises an exposed server, Barney said the threat rarely stops at initial access: attackers immediately hunt for persistent credentials, API tokens, cloud keys, and elevated roles embedded in automated workflows to expand their reach within the organization.
Barney added that defending CI/CD infrastructure requires security teams to shift from perimeter patching to proactive access controls. Organizations must treat build platforms as privileged assets and enforce zero-trust security at the identity layer.
“By enforcing automated credential rotation, implementing time-limited access and maintaining strict governance across human operators, AI agents and machine identities, security teams can drastically shrink their attack surface,” said Barney. “Even when an unpatched vulnerability exposes a server, disciplined privilege governance ensures an initial foothold cannot escalate into a systemic supply chain breach.”
Waseem Ahmed, head of engineering at Secure.com, added that while a 10.0 flaw with no login required is bad enough, what’s worse is where it lands: GitLab servers are not ordinary web servers, they hold source code, deploy keys, runner tokens, and the credentials that push to production.
“Anyone who gets code execution there can change what you ship, and the damage shows up later inside software your customers already trust,” said Ahmed. “The supply chain concern is reasonable, even though I haven't seen a downstream compromise reported.”
Ahmed said he’s not bothered by the 1,000 number: it’s the time since the flaw was patched that matters.
“A patch has been available since mid-October and these servers still haven't taken it, which often points to servers nobody owns,” said Ahmed. “Self-managed GitLab tends to sit with engineering and never makes the security asset list. Patching closes the door without evicting whoever is already inside. Check your version today and patch. If the instance doesn't need to face the internet, take it off. If it was exposed, rotate every token and key on it, and hunt for new accounts, tokens or CI jobs you didn't create.”
Sina Chehreghani, head of threat intel and threat research at Securonix, explained that the flaw sits in GitLab’s CI/CD Regular Expression Compiler, which parses regular expressions in pipeline configuration files. An unauthenticated attacker can submit a specially crafted expression that triggers an integer overflow and may execute code on a vulnerable GitLab server.
From there, Chehreghani said the attacker could inspect project data and CI/CD variables, access credentials available to the server, or alter pipeline configuration.
“Security teams should patch exposed self-managed instances and review GitLab logs for crafted CI configuration submissions, followed by unusual processes, account or token creation, repository access, pipeline changes, or runner activity,” said Chehreghani.
Justin Beals, founder and CEO at Strike Graph, said many teams leave a SaaS platform to avoid depending on a single vendor. Self-hosting GitLab gives teams control, but it also hands them the vendor’s patching job.
Beals said a self-managed team inherits the work of reading release notices, testing upgrades, and scheduling downtime on GitLab’s release calendar. GitLab combines patch and security fixes into planned releases and issues critical releases when needed. However, Beals pointed out that a team that patches quarterly leaves every fix unapplied for up to three months.
“In the agentic era, attackers can probably turn a published fix into a working exploit within days, because AI tools make reading a patch cheap,” said Beals. “Exposed servers are easy to find. Self-hosting is still defensible, but it requires a patch process measured in days, staffed before the vulnerability arrives."
