On Thursday, CISA added a GitLab flaw to its Known Exploited Vulnerabilities catalog. That catalog is not a list of things that might be a problem someday. It is the list of flaws CISA says are being exploited in the real world. When something lands there, I stop treating it as routine patching and start treating it as urgent.
The flaw is CVE-2026-97229, and it carries the highest score there is: 10.0 out of 10. It affects self-managed GitLab Community Edition and Enterprise Edition. According to CISA and The Hacker News, it is an integer overflow in how GitLab handles a specially crafted regular expression in a CI/CD configuration, and it can let an unauthenticated user — no login, no account — execute arbitrary code on the GitLab server.
Let me put that in plain terms. GitLab is where a lot of teams keep their source code and run their build pipelines. If an attacker can run their own code on that server without logging in, they are not just knocking on the door. They are inside the building where the code, the build jobs, and often the secrets those jobs use all live. That is why a 10.0 here is not hype. The score matches what is actually at stake.
Who is affected
If you use GitLab.com, you can relax a little: GitLab says that service was already patched before disclosure, and GitLab Dedicated customers do not need to act. The work falls on people like me who run servers themselves — anyone with a self-managed GitLab instance.
GitLab fixed this on October 12 in versions 19.2.8, 19.3.5, and 19.4.2. The affected ranges are 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. If your instance is in one of those ranges, upgrade to the fixed release for your branch — or to the newest release on that branch — now, not at your next maintenance window. CISA has told federal civilian agencies to apply the fixes by November 1, 2026. That deadline only legally binds those agencies, but it tells the rest of us how seriously to take the timeline.
The Alpine Linux lesson: upgrading GitLab may not be enough
The most useful part of this story is what happened to Alpine Linux, and it is the part I want every self-hosting admin to read twice.
An attacker targeted Alpine’s own GitLab instance on October 20 and 21, sending crafted CI configurations that crashed its GitLab worker processes eight times. In four of those crashes, the exploit failed at the next step. Alpine’s team said it plainly: “The attack came close to working.” They found no evidence it succeeded, but they could not rule it out, so they treated the instance as compromised and rebuilt it from scratch. Their checks showed the aports repository, packages, and the October 21 releases were not tampered with. Follow-up attempts on October 25 and 26 were blocked.
Here is the catch they uncovered. GitLab’s fix is a patch to the Ruby that GitLab bundles inside its own packages and container images — the bug itself sits in Onigmo, the regular expression engine built into Ruby. Alpine’s image used a standard Ruby, so upgrading to GitLab 19.3.6 on October 22 did not close the hole. If you built GitLab from source, or your container image installs its own Ruby, upgrading GitLab alone leaves you exposed. Those installs also need Ruby updated to 3.3.13, 3.4.12, 4.0.9, or later. Ruby 3.2 will not get this fix, so a server on 3.2 needs a real Ruby upgrade, not just a patch.
That is a lesson that goes well beyond GitLab: a patch only fixes the copy of the code it actually touches. Know how your software was built before you assume an upgrade covered you.
What I would do today
First, check your GitLab version and how it was installed — official package, official image, or your own build with your own Ruby. Second, upgrade GitLab to a fixed release, and if there is a separate Ruby in the picture, upgrade that too, then verify the running versions, not just the installed ones. Third, look back at your logs around any worker crashes or strange CI configuration activity — repeated crashes are exactly what Alpine saw while someone was probing them. Fourth, if you find signs someone was testing this against you, do not just patch and move on. Alpine rebuilt from scratch because they could not rule out success. Copy that caution.
One more from the same CISA update: Cisco’s CVE-2026-76418, scored 8.6, lets an unauthenticated remote attacker reload Cisco Secure Firewall ASA and FTD devices running SSL VPN, causing a denial of service. Cisco says it saw active exploitation in October, fixes are out, and if you cannot patch right away, Bleeping Computer notes Cisco’s mitigation of disabling secondary authentication on the DefaultWEBVPNGroup tunnel group. If you run those firewalls with SSL VPN enabled, that is your second job today.
Patch the thing that is actually exploitable, verify the patch actually landed, and check whether anyone came knocking while you were exposed. That order matters.
Sources: The Hacker News on the CISA KEV addition (https://thehackernews.com/2026/10/cisa-adds-actively-exploited-gitlab-rce.html), The Hacker News on the Alpine Linux attack (https://thehackernews.com/2026/10/attacker-tried-to-exploit-alpine-linuxs.html), Rapid7’s analysis of CVE-2026-97229 (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/), and Bleeping Computer on the Cisco flaw (https://www.bleepingcomputer.com/news/security/cisco-warns-of-firewall-zero-day-exploited-to-crash-ssl-vpn-devices/).