Ing. Calogero Bono
On October 12, 2026, GitLab released versions 19.4.2, 19.3.5 and 19.2.8 for Community Edition and Enterprise Edition. They include the fix for CVE-2026-97229, a flaw with a CVSS score of 10.0 that can lead to arbitrary code execution on the server. On Thursday, the US agency CISA confirmed active exploitation and added it to the KEV catalog. If you run a self-managed GitLab instance, the priority is updating right away.
A few terms before we get into the facts. CVE is the code that identifies a public vulnerability. CVSS is the severity score from 0 to 10. CI/CD refers to the automated pipelines that build, test and publish code. KEV is CISA's catalog of flaws already exploited in real attacks. RCE means remote code execution, that is, running commands on someone else's server.
What is CVE-2026-97229?
According to the official GitLab page, it is an integer overflow issue in the regular expression compiler used for CI/CD configurations. Under certain conditions, an unauthenticated user could run arbitrary code on the server using a carefully crafted regular expression, due to insufficient validation.
The CVSS vector is network-based, with low complexity, no privileges required and no user interaction. That is why the score reaches 10.0. The flaw was reported by joaxcar through the HackerOne bug bounty program.
Who is exploiting it?
As reported by BleepingComputer, CISA added the flaw to the KEV and asked federal agencies to secure their servers by Sunday. According to The Hacker News, the deadline for civilian agencies is November 1, 2026.
The listing is tied to an incident disclosed by Alpine Linux. An unknown actor tried unsuccessfully to exploit the flaw on its instance on October 20 and 21, 2026. They sent specially crafted CI configurations and crashed the worker processes eight times. In four of those cases the exploit failed at the next step. The attacker also downloaded Alpine's GitLab container image. New attempts on October 25 and 26 were blocked.
Alpine's maintainers stated "The attack came close to working". They added that they found no evidence of success, but cannot rule it out, which is why they rebuilt the instance from scratch. According to them, the aports repository, the packages and the releases from October 21 were not tampered with.
Which versions are affected?
For CVE-2026-97229, GitLab lists all versions from 19.2 before 19.2.8, from 19.3 before 19.3.5, and from 19.4 before 19.4.2. GitLab.com already runs the fixed version. GitLab Dedicated tenants were updated with an internal release before publication.
GitLab also notes that 19.3.4 had a bug on merge request pages with the Ona integration enabled. It is fixed in 19.3.5. The company has also released six threat detections to help self-managed operators spot exploitation attempts.
Other flaws in the same patch
The release does not contain only the most severe case. Among the other fixes, with the scores declared by GitLab.
- CVE-2026-92883, cross-site scripting in syntax highlighting, CVSS 8.7.
- CVE-2026-16301, a Developer user could start pipelines on protected branches, CVSS 8.5.
- CVE-2026-14814, raw file cache poisoning, with possible exposure of protected variables, CVSS 8.2.
- CVE-2026-81839, pipelines run with the privileges of the new group after a project transfer (EE only), CVSS 7.7.
- CVE-2026-96893, injection into the instructions of GitLab Duo AI agents (EE only), CVSS 7.3.
There are also five medium-severity flaws, including reading confidential notes via GraphQL and token exposure in GitLab Pages logs. The full picture is on the official page.
Limits to keep in mind
We do not know how many instances have been compromised. Shadowserver, cited by BleepingComputer, tracks nearly 2,800 Community Edition instances exposed on the Internet, but does not indicate how many are already updated. That number should not be read as a count of vulnerable systems.
The sources do not say who the attacker is or whether there are cases beyond Alpine. The technical details of the exploit have not been published. GitLab makes vulnerability reports public 90 days after the patch release, so more details may emerge.
What changes for people working in digital
If you run a self-managed GitLab for your studio or company, the priority is the version. An unauthenticated flaw on a server that holds code, secrets and pipelines is a concrete risk, including for your clients. Those who host their repositories on GitLab.com are already protected on the platform side.
Alpine's lesson is practical. If you cannot rule out a compromise, rebuild the instance and rotate your secrets. Automating installations helps, as we explain in the guide on Ansible for configuration and deployment. Servers also require discipline in updates, a topic we covered in the cases of Fragnesia and PHP2Shell. Another recent example of scans after a patch is Oracle E-Business Suite. If you do not have time to follow everything, there are managed hosting and servers with security updates.
Our take
This case shows how short the time between patch and attack can be. The fix came on October 12, the attempts on Alpine on the 20th, so eight days. If you update on the next monthly cycle, you are already too late.
There is a critical note too. GitLab is cited as present in over half of the Fortune 100, and BleepingComputer lists a string of maximum-severity flaws in the same period, including two more of top severity. For a service that guards a company's code and secrets, that frequency weighs heavily. Saying GitLab patches quickly is not enough, even though it does. Those who decide to keep everything in-house must budget for continuous oversight, or entrust it to those who do this for a living.
Frequently asked questions
Should I update GitLab right away?
Yes, if your instance is self-managed and running one of the affected versions. GitLab recommends an immediate update to 19.4.2, 19.3.5 or 19.2.8. Active exploitation is confirmed by CISA.
Is GitLab.com at risk?
No, according to GitLab. GitLab.com already runs the fixed version, and Dedicated tenants were updated before the public release.
Do you need an account to exploit the flaw?
No. The CVSS vector indicates no privileges required and no user interaction. The attack goes through a carefully crafted CI/CD configuration.
How do I know if I have been attacked?
The sources offer no certain method. GitLab has released six detections for self-managed instances. Alpine saw repeated worker crashes following unusual CI configurations.
Is updating enough?
It depends. If the instance was exposed and unpatched in the preceding days, you cannot rule out a compromise. Alpine chose to rebuild it from scratch.
What to watch in the coming weeks, between patches and checks
In the coming days, what matters is whether other cases beyond Alpine emerge and whether technical details are published. Three recommendations.
- Update to the latest available version for your branch and check the version number after installation.
- Check worker logs for repeated crashes and unusual CI configurations, using GitLab's detections.
- If the instance was exposed and not updated, rotate tokens and protected variables and consider rebuilding.
