GitLab CVE-2026-97229 Exploited: CISA KEV, CVSS 10 CI/CD Regex RCE and What to Rotate

CISA added GitLab CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog on October 29, 2026, with a federal remediation deadline of November 1. The flaw is a CVSS 10.0 integer overflow in the regular expression compiler used for CI/CD configuration. Under certain conditions, GitLab says, an unauthenticated user could execute arbitrary code on a self-managed GitLab server. If you run GitLab 19.2, 19.3 or 19.4 below the fixed releases, patch now and assume that anything the server holds, including CI secrets and runner tokens, may need rotating.

This is the first of two regex-compiler remote code execution bugs GitLab fixed in October. Our earlier post on CVE-2026-110264 covers the second, wider one. This post is the breakdown of the one attackers are now using: what the advisory and CISA say, the timeline, who is affected, what to check, and why a GitLab compromise matters to anyone whose coding agents push code through it.

TL;DR

What the sources say

GitLab's 19.4.2 patch release notes describe CVE-2026-97229 as an integer overflow in the CI/CD regular expression compiler, rated Critical with a CVSS score of 10.0. The cause listed is insufficient regular expression validation. The reporter credited is joaxcar, via GitLab's HackerOne program. GitLab says the issue details will be made public 90 days after the release, so the exact trigger and exploit mechanics are not yet published by the vendor.

CISA's KEV entry for GitLab CE and EE lists the date added as 2026-10-29 and the due date as 2026-11-01. Known ransomware use is listed as "Unknown". The required action is to apply vendor mitigations and comply with CISA's BOD 26-04, with forensic triage required, and to assess each asset's internet exposure.

Two details are worth separating. First, the KEV listing is the confirmation that exploitation happened; the GitLab release page does not itself say so. Second, our attacks tracker records the incident as exploited from around October 12, the day of the patch release. We have not independently verified the first exploitation date or who exploited it, and CISA does not state either. Treat "October 12 onward" as the window in which an unpatched server could have been hit, not as a confirmed start of attacks.

The attack chain, as far as it is public

GitLab has not published a proof of concept, and we have not run one. What is documented gives this chain:

1. Reach a CI/CD configuration parser. The vector is network, low complexity, no privileges and no user interaction (AV:N/AC:L/PR:N/UI:N). GitLab's wording that an unauthenticated user can trigger the bug means an attacker needs no account on the instance.
2. Supply a crafted regular expression. CI/CD configuration accepts regular expressions in several places, and GitLab's engine compiles them on the server. A pattern built to overflow an integer during compilation corrupts memory.
3. Run code on the GitLab server. The scope is marked changed (S:C) and confidentiality, integrity and availability are all High. Code execution on the application server is the realistic outcome.
4. Harvest what the server holds. From there an attacker can read repository contents, CI/CD variables, runner registration tokens, deploy keys and tokens for connected services, then pivot into the build and production systems those credentials unlock.

That last step is why a score of 10.0 here is not abstract. A GitLab server is a credential store with an HTTP front door. The same logic drove our analysis of the Railway breach: the first compromise is rarely the expensive one, the secrets it exposes are.

The six detections GitLab published

GitLab released six threat detections for self-managed customers to help identify exploitation attempts. Their names, from the release notes, are:

• Onigmo native worker crash
• Graphql cilint hostile regexp
• ci regexp oversized non ascii path
• ci regexp guard rejection
• ci lint workhorse worker crash
• ci lint scripted client error burst

The names point at where to look: native crashes of the workers that compile patterns, hostile regular expressions arriving through the GraphQL CI lint endpoint, oversized non-ASCII patterns, rejections by a new guard, and bursts of scripted errors against the CI lint endpoint. If you cannot use the detections, search your reverse proxy and application logs for repeated requests to CI lint and GraphQL endpoints from unauthenticated clients, and for Puma or Sidekiq worker crashes.

Timeline

Who is affected

Only self-managed installations on the three affected lines. GitLab.com and GitLab Dedicated were patched by GitLab. Versions older than 19.2 are not listed as affected by this CVE, but they are not safe to ignore: our post on CVE-2026-110264 covers a regex flaw that reaches back to 7.0. The Beam CVE database has entries for CVE-2026-97229 and the follow-up CVE-2026-110264.

The people most at risk are teams with an internet-reachable GitLab, because the bug needs no credentials. Instances reachable only through a VPN or an identity-aware proxy have a much smaller exposure, though an insider or a compromised laptop on that network could still reach them.

What this means if you run AI coding agents

Coding agents increasingly work through GitLab: they clone repositories, push branches, open merge requests and trigger pipelines with tokens of their own. That changes the blast radius of a server compromise in three ways.

• Agent tokens live on the server. A personal or project access token minted for an agent is just another secret the attacker can read. Rotate them with everything else, and prefer short-lived, project-scoped tokens with expiry dates.
• Repository content can be tampered with. An attacker with code execution can alter files that agents later read, including instruction files, skills and MCP configuration checked into repositories. After any suspected compromise, review recent commits to those files before letting an agent run on a fresh checkout. See how a poisoned MCP config becomes code execution for why that matters.
• Pipelines run with broad credentials. Pipelines that agents trigger often carry cloud keys and package registry tokens. The LiteLLM compromise and the OVHcloud CLI release swap both show how quickly stolen CI-adjacent secrets get used.

Checks to run today

Check your version:

sudo gitlab-rake gitlab:env:info

If you are on an affected line, upgrade to 19.2.8, 19.3.5, 19.4.2 or later. To cover CVE-2026-110264 as well, use the October 21 releases listed in our earlier post. If you cannot patch immediately, take the instance off the public internet: a VPN, IP allow list or identity-aware proxy. The advisory lists no workaround, so this is a risk-reduction step, not a fix.

Then look for signs of compromise:

• Admin users, personal access tokens, SSH keys, deploy keys or runner registrations you did not create
• Changes to CI/CD variables, protected branches or project settings
• Pipeline definitions that were edited and reverted, or jobs that print environment variables
• Unexpected processes owned by the git user and unexplained outbound connections from the GitLab host
• Any hit on the six detections above

If anything matches, rotate in this order: CI/CD variables and cloud credentials used by pipelines, runner tokens, deploy keys, access tokens used by people and agents, then OAuth application secrets. Because CISA calls for forensic triage under BOD 26-04, preserve logs and a disk snapshot before rebuilding.

What Beam can and cannot do here

Beam runs on the developer's machine, not on your GitLab server, so it cannot see or stop this attack. It cannot patch GitLab or detect a malicious regex against it.

What it can help with is the agent side afterwards. Beam records the shell and git commands that Claude Code and Codex run, and flags credential exposure in agent sessions, with secrets redacted before they are stored. If you need to answer "what did our agents push or run during the exposure window," those local records are one place to look, as described in how Beam watches agents. Its scan of skills and MCP configs is heuristic, and a hook-based deny only covers harnesses that support it. It is not a substitute for patching the server.

What developers are saying

We did not find a Hacker News discussion tied to this specific CVE at the time of writing, so there is no community commentary to summarize. We will add it here if one appears.

Frequently asked questions

What is GitLab CVE-2026-97229?

It is a CVSS 10.0 integer overflow in the regular expression compiler used for CI/CD configuration. GitLab says that, under certain conditions, an unauthenticated user could execute arbitrary code on a self-managed GitLab server using a specially crafted regular expression.

Which GitLab versions are affected and fixed?

All versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 are affected. The fixed releases are 19.2.8, 19.3.5 and 19.4.2. GitLab.com and GitLab Dedicated are already patched.

Is CVE-2026-97229 exploited in the wild?

CISA added it to the Known Exploited Vulnerabilities catalog on October 29, 2026, with a due date of November 1 and forensic triage required under BOD 26-04. GitLab's advisory page itself does not say whether exploitation was observed.

Does patching 19.4.2 fully protect me?

It fixes this CVE, but a separate regex flaw, CVE-2026-110264, was fixed only in the October 21 releases such as 19.5.1 and 19.4.3. Move to those or later to cover both.

What should I rotate if I was exposed?

Treat everything the GitLab server holds as exposed: CI/CD variables, runner registration and authentication tokens, deploy keys, personal and project access tokens (including ones used by coding agents), OAuth application secrets and cloud credentials used by pipelines.

Related reading

• GitLab CVE-2026-110264: the second CVSS 10 regex RCE
• Railway breach: rotate every secret
• LiteLLM 1.107.0 compromise
• OVHcloud CLI release binaries swapped for an infostealer
• Node.js October 2026 security release and MCP servers
• October 2026 attacks timeline and the attacks tracker

Primary sources: GitLab 19.4.2 patch release · CISA KEV entry for CVE-2026-97229

Accurate as of October 30, 2026. GitLab will publish the issue details 90 days after the release, and this post will be updated if the vendor or CISA add exploitation details.