What happened
On 12 October GitLab fixed CVE-2026-97229, an integer overflow in its CI/CD regular expression compiler that could let an unauthenticated user run code on the server. It rated the flaw CVSS 10.0 and shipped 19.4.2, 19.3.5, and 19.2.8. GitLab.com was already patched and GitLab Dedicated customers needed no action (vendor, via Help Net Security). Rapid7 published proof-of-concept code the next day, and Censys counted 25,766 internet-facing hosts on vulnerable versions (independent, SecurityOnline).
On 28 October Alpine Linux published what happened to its own GitLab (vendor, Alpine Linux). It had upgraded to 19.3.4 instead of 19.3.5 “by mistake” on 13 October. On 20 and 21 October a newly registered account sent crafted CI configurations that crashed GitLab workers eight times; in four of those the exploit got partway. On 22 October Alpine upgraded to 19.3.6. That did not fix it either. The attacker returned on 25 and 26 October and failed. Alpine closed GitLab to everyone but developers and build servers on 27 October, rebuilt it, reset every password, and replaced its secret keys.
Alpine found no evidence the exploit succeeded and says it cannot rule out code execution, because a success would leave no crash and some logs from the attack day are gone. It says its 21 October releases were not tampered with and that its signing keys were never on the GitLab server (vendor).
The version trap
The bug sits in Onigmo, Ruby’s regular expression engine. Per Alpine, GitLab’s fix is a Ruby patch that GitLab applies only in its official packages. Alpine’s image ran GitLab on standard Ruby, so 19.3.6 carried the GitLab version number of a fixed release and the Ruby of an unfixed one. Upstream Ruby shipped the fix on 23 October in 3.3.13, 3.4.12, and 4.0.9 (vendor, Alpine).
Most patch dashboards check the GitLab version. For anyone running GitLab on a Ruby they did not get from GitLab, that check answers the wrong question.
The fair counterpoint: most enterprises run GitLab’s official Omnibus packages, Helm chart, or images, which carry the patched Ruby. The trap is for the minority on distribution packages, community images, or source installs. The question is whether you know which group each of your instances is in.
Who is patched
| How you run GitLab | Patched when | Check |
|---|---|---|
| GitLab.com | Already, per GitLab (vendor) | None |
| GitLab Dedicated | No action needed, per GitLab (vendor) | None |
| Official self-managed packages, chart, or images | On 19.2.8, 19.3.5, 19.4.2, or later | GitLab version |
| Distribution packages, community images, source installs, or any non-GitLab Ruby | When Ruby is 3.3.13, 3.4.12, 4.0.9, or later (vendor, Alpine) | The Ruby version inside the running service |
Alpine’s alpinelinux/gitlab image | 19.3.6 pulled on or after 27 Oct; earlier pulls and older tags are vulnerable (vendor, Alpine) | Re-pull and redeploy |
The attack needs a foothold first. Rapid7 says an attacker must be able to commit a malicious .gitlab-ci.yml to a branch in a public project, which an ordinary account can do on instances that let users create public projects (independent, via Help Net Security). At Alpine it was a newly registered account.
If you were exposed
If an instance ran vulnerable code while open to registration or public projects, treat it the way Alpine did. Alpine’s list of what a successful exploit would have reached is a usable rotation list (vendor):
- Password hashes and 2FA secrets: force resets.
- CI/CD variables and runner tokens: rotate both, and the cloud credentials the variables hold.
- Webhook, integration, and push mirror credentials.
- Personal access tokens.
- Private repositories and confidential issues: review for anything that should not have been there.
Five steps
- Step 1. Classify every instance. Official package, chart, or image, or anything else. Owner: platform engineering.
- Step 2. Check the right version. GitLab version for the first group; Ruby version inside the running service for the second. Owner: platform engineering.
- Step 3. Close the foothold until patched. Turn off open registration and public project creation on any instance not yet confirmed. Owner: GitLab administrator.
- Step 4. Rotate if exposed. Use the list above for any instance that was vulnerable and reachable after 13 October, when the proof of concept went public. Owner: security engineering.
- Step 5. Add the runtime to the patch check. For any application that bundles its own runtime fix, record the runtime version alongside the application version. Owner: vulnerability management.
Shipping the fix is GitLab’s job. Knowing which Ruby your GitLab runs on is ours.
Missing
- A statement from GitLab on which installation methods carry the patched Ruby. The version-trap detail comes from Alpine’s account.
- How many self-managed instances run on a non-GitLab Ruby. Nobody has published a count.
- Confirmed exploitation. As of 28 October the CVE was not in CISA’s catalogue (independent, SecurityOnline).
- Alpine’s logs from the attack day, some of which are gone.
Frequently asked questions
We are on GitLab 19.4.2 or later. Are we safe?
If you run GitLab’s official packages or images, yes: GitLab ships its patched Ruby with them. If your GitLab runs on a Ruby you or a distribution supplied, you are patched only when that Ruby is 3.3.13, 3.4.12, 4.0.9, or later, which upstream released on 23 October.
Is CVE-2026-97229 being exploited?
Alpine Linux reports an attempted exploitation of its own GitLab on 20 and 21 October and again on 25 and 26 October. It found no evidence the attempt succeeded and could not rule it out. Rapid7 published proof-of-concept code on 13 October. As of 28 October the CVE was not in CISA’s Known Exploited Vulnerabilities catalogue.
What should we rotate if our instance was exposed?
Alpine treated its server as compromised: it rebuilt GitLab, reset every password, and replaced GitLab’s secret keys. Its list of what an attacker could have reached includes password hashes, 2FA secrets, CI/CD variables, runner tokens, webhook and integration credentials, push mirror credentials, and private repositories.
Living page. Last updated 29 Oct 2026. We update this note if GitLab clarifies which installation methods are affected or if exploitation is confirmed.