GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound Vulnerability
TL;DR 📌
- GitLab Community Edition and Enterprise Edition contain a integer overflow or wraparound vulnerability that could allow an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.
- Highest CVSS: 10.0 (Critical).
- Listed in CISA KEV (2026-10-29) — this is being exploited in the wild.
- Fixed in
19.2.8,19.3.5,19.4.2— upgrade to this release or later. - CVEs: CVE-2026-97229.
What it is
CVE-2026-97229 is an integer overflow or wraparound flaw in GitLab Community Edition and Enterprise Edition. It sits in the regular expression handling used for CI/CD configuration — specifically, insufficient validation of regular expressions supplied in that configuration allows the overflow condition to be triggered.
The path to the vulnerable code does not require authentication. An attacker submits a specially crafted regular expression inside a CI/CD configuration, which GitLab processes, triggering the overflow. The result is arbitrary code execution on the GitLab server itself — not on a runner or sandboxed build environment, but on the server running GitLab.
This is a network-reachable, unauthenticated code execution path with no privileges and no user interaction required (AV:N/AC:L/PR:N/UI:N in the scoring vector), and the impact covers confidentiality, integrity and availability in full. The scope is marked changed, meaning the flaw affects resources beyond the vulnerable component itself.
The vulnerability is listed in CISA’s Known Exploited Vulnerabilities catalogue, added on 29 October 2026, so it is known to be exploited.
What to do
- Patch to GitLab 19.2.8, 19.3.5, or 19.4.2 depending on your current release line — these are the fixed versions GitLab has published for the affected 19.2, 19.3 and 19.4 branches.
- Treat this as urgent: unauthenticated remote code execution on the GitLab server, combined with confirmed exploitation, means patching should not wait for a normal maintenance window.
- If you cannot patch immediately, restrict network access to the GitLab instance (particularly from untrusted or public networks) while you schedule the update.
- Review CI/CD pipeline configurations and server logs for unexpected regular expression patterns or signs of unauthorised code execution predating the patch, given the KEV listing.
- Confirm your deployed version against the three affected ranges (19.2 before 19.2.8, 19.3 before 19.3.5, 19.4 before 19.4.2) — versions outside these ranges are not confirmed affected by this advisory, so consult GitLab’s release notes if you’re running an older or newer major version.
For leadership 🧭
Executive summary. Risk is Critical (CVSS 10.0) across any GitLab kit you run. Follow the remediation in the vendor advisory within Immediate — CISA KEV entries carry a federal remediation deadline.
Why it matters:
- Exposure depends on deployment topology and which access paths reach the affected component.
- Treat internet-facing and management-plane instances as higher risk than internal-only ones.
- Keep monitoring for abnormal authentication and configuration events until upgrades complete.
Now / Next / Later:
- Now: confirm whether you run the affected versions, and check exposure of any that are internet-facing.
- Next: apply the remediation the advisory specifies, through an approved change window.
- Later: add a control check so builds cannot drift back onto a vulnerable train.