The vulnerability stems from insufficient validation of regular expressions used in CI/CD configurations. Exploitation requires an attacker to place a malicious configuration in a repository, a condition that may be relatively easy to meet on instances allowing public project creation.
Rapid7 has successfully reproduced the exploit, although there are currently no confirmed reports of exploitation in the wild.
Why This Vulnerability Matters
What makes CVE-2026-97229 especially dangerous is not just the possibility of remote code execution, but where that execution takes place.
GitLab is more than a code repository. It sits at the intersection of source code, developer credentials, build pipelines, and software releases. Compromising that environment could give an attacker access to sensitive information, allow them to manipulate build processes, and potentially affect software delivered to downstream customers.
An attacker doesn’t need to compromise every developer workstation if they can manipulate a trusted point in the software release process. That’s what makes this vulnerability a serious software supply chain concern.
What Organizations Should Do
My recommendation is straightforward: treat CVE-2026-97229 as an emergency patching priority. Affected self-managed GitLab instances should be upgraded immediately to versions 19.2.8, 19.3.5, or 19.4.2, rather than waiting for the next maintenance window. GitLab.com is already patched.
But patching alone isn’t enough. Organizations should also review access permissions, examine logs and recent CI/CD changes for suspicious activity, and assess whether credentials or secrets may have been exposed.
A patch closes the known vulnerability. It doesn’t tell you whether an attacker exploited it before the fix was applied. Understanding that potential exposure is just as important as deploying the update.
