CISA, the US Cybersecurity and Infrastructure Security Agency, added two exploited flaws to its Known Exploited Vulnerabilities (KEV) catalog on 29 October: CVE-2026-97229, a CVSS 10.0 remote code execution (RCE) flaw in self-managed GitLab, and CVE-2026-76418, a denial-of-service (DoS) flaw in Cisco Secure Firewall ASA and FTD VPNs.1 If you run self-managed GitLab, upgrade today to 19.5.1, 19.4.3, 19.3.6, 19.2.9 or the matching 21 October build for an older branch, because the 12 October builds fix only this flaw and not a second CVSS 10.0 one; if you run an ASA or FTD VPN with secondary authentication, patch this week; if you run neither, confirm that by Monday.
CISA listed one GitLab flaw and one Cisco flaw on 29 October
Rapid7 records CISA adding CVE-2026-97229, in GitLab Community Edition (CE) and Enterprise Edition (EE), to KEV on 29 October, based on evidence of active exploitation, meaning attackers are using the flaw against real targets.2 Each flaw is tracked under a CVE (Common Vulnerabilities and Exposures) identifier and scored on CVSS (Common Vulnerability Scoring System). The Hacker News reports that the Cisco flaw, CVE-2026-76418 in Cisco Secure Firewall ASA and Secure FTD software, went on the list the same day, and that federal agencies have until 1 November to apply the fixes.1 Microsoft's record Patch Tuesday fixed 1,411 flaws on 13 October by BleepingComputer's count,3 so teams still working through that backlog now have two exploited flaws to rank above it.
GitLab's 12 October fix leaves a second CVSS 10.0 flaw open
GitLab fixed CVE-2026-97229 on 12 October in 19.4.2, 19.3.5 and 19.2.8, shipped as a critical patch release, in effect a hotfix: a targeted update for one specific problem. The flaw is an integer overflow, a calculation whose result exceeds the space reserved for it, in the CI/CD (continuous integration and continuous delivery) regular expression (regex) compiler. GitLab says it could let an unauthenticated attacker, one with no account or login, run code on the server through a crafted regex in a CI/CD configuration.4
Measured Rapid7 reproduced code execution as the GitLab git user on an unpatched official 19.4.1 image, and the same input failed on 19.4.2.2 Its route needs a way to commit a CI file to a public project, which a server with open self-registration and project creation gives any visitor.2 Rapid7 published proof-of-concept code on 13 October.2
Reported Alpine Linux disclosed an attempted attack on its own GitLab server, which ran 19.3.4 rather than 19.3.5. A newly registered account sent crafted CI configurations on 20 and 21 October that crashed GitLab workers eight times, and the attacker returned on 25 and 26 October. Alpine found no evidence the code ran but cannot rule it out, because some logs from the period no longer exist.5 GitLab first named 19.3.4 as the 19.3 fix and later replaced it with 19.3.5, so 19.3.4 counts as affected.5
GitLab's 21 October release fixes CVE-2026-110264, a second CVSS 10.0 integer overflow in GitLab's regex compiler. GitLab describes it as exploitable by an unauthenticated user, and it reaches back to GitLab 7.0. GitLab's notice lists 19.4 before 19.4.3, 19.3 before 19.3.6 and 19.2 before 19.2.9 as affected, so a server on the 12 October builds is still exposed to the second flaw.6
Cisco's flaw reboots a firewall without a login
Reported Cisco published security advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 on 28 October and said its Product Security Incident Response Team (PSIRT) learned of active exploitation in October. CVE-2026-76418 scores CVSS 8.6 and comes from logic errors when secondary authentication is configured on a tunnel group in the remote-access SSL VPN (virtual private network over TLS) service. That makes the firewall a VPN gateway, the point where remote users connect. A crafted connection request lets an unauthenticated remote attacker reload the firewall, and Cisco says a successful VPN login is not required to reach the affected code.7 Cisco has not named the attackers or said how many organizations were targeted.1 The sources I read describe a reload and no code execution or data theft.
A device is exposed only if it runs an affected release, has webvpn enabled on at least one interface, and has secondary-authentication-server-group set on a tunnel group or on DefaultWEBVPNGroup. Cisco lists Cloud-delivered Firewall, cdFMC, Secure Access and Secure FMC as not affected.7
Opinion Patch GitLab first. A GitLab server holds source code repositories and CI/CD secrets, and this flaw gives code execution on it. A reload costs you VPN availability until the device returns. Patch Cisco this week anyway, because Cisco says no complete workaround exists.7
Who is affected, and which builds fix it
| Product and flaw | Exploited? | Affected | Fixed |
|---|---|---|---|
| GitLab CVE-2026-97229 | Yes, KEV 29 Oct2 | CE/EE 19.2 before 19.2.8, 19.3 before 19.3.5, 19.4 before 19.4.24 | 19.4.2, 19.3.5, 19.2.8, superseded by the row below |
| GitLab CVE-2026-110264 | Not stated in GitLab's notice6 | CE/EE from 7.0 before 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, 19.5.16 | 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, 19.5.16 |
| Cisco ASA CVE-2026-76418 | Yes, KEV 29 Oct1 | ASA 9.16 through 9.24 with SSL VPN and secondary authentication7 | 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27, 9.24.10.17 |
| Cisco FTD CVE-2026-76418 | Yes, KEV 29 Oct1 | FTD 7.0 through 10.1 with SSL VPN and secondary authentication7 | 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, 10.1.17 |
Only self-managed GitLab needs action, meaning deployments you run on your own servers. GitLab.com is already patched, and GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later already include the 21 October fixes.6
If GitLab runs on your own Ruby, upgrading GitLab alone may not close the flaw. GitLab's fix patches the Ruby inside its own Linux packages and container images, so a self-compiled install, or an image that installs Ruby separately as Alpine's did, stays vulnerable until Ruby itself is updated. Ruby's fixed versions are 3.3.13, 3.4.12 and 4.0.9, and Ruby 3.2 will not get one.5
No source I opened reports exploitation of CVE-2026-110264, and it is not among the two entries CISA added on 29 October.1 I found no public count of compromised GitLab servers, and Alpine could not rule out code execution on its own. I could not open Cisco's advisory or CISA's alert, so the Cisco details come from SecurityOnline quoting the advisory.7
Upgrade GitLab first, then patch Cisco VPN firewalls
GitLab goes ahead of Cisco because vulnerability prioritization should follow exploitation, internet exposure and what the system holds, which is the core of risk-based vulnerability management. How to prioritize exploited vulnerabilities explains why exploitation status, not CVSS score, sets the order for a whole queue.
- Build an asset inventory of every self-managed GitLab CE and EE instance, recording its branch and whether it runs GitLab's bundled Ruby or your own.
- Apply the security patch: upgrade each instance to 19.5.1, 19.4.3, 19.3.6 or 19.2.9, or to 19.1.9, 19.0.10 or 18.11.13 on older branches, or to a later patch of your branch. Plan downtime on single-node installs, because 19.4.3 and 19.3.6 run database migrations.6
- Update Ruby to 3.3.13, 3.4.12 or 4.0.9 or later if you compile GitLab from source or run an image that installs its own Ruby, and move off Ruby 3.2.5
- Start threat hunting, a search of your logs for attacker traces, with GitLab's published detections: six for CVE-2026-97229, including the Onigmo native worker crash, and two for CVE-2026-110264.46
- Run forensic triage, a quick first assessment of what an attacker reached, on any server that shows signs of code execution: look for files owned by the git user in /tmp, unexpected child processes of Puma or Sidekiq, outbound connections, and changed crontabs or SSH keys for the git user.5
- Begin credential rotation on a compromised server: replace the secrets in gitlab-secrets.json, all CI/CD variables, all runner tokens and all access tokens.5
- Find every Cisco ASA and FTD VPN gateway with
webvpnenabled on an interface andsecondary-authentication-server-groupset on a tunnel group or on DefaultWEBVPNGroup.7 - Upgrade those devices to the first fixed release for your train from the table above this week.7
- If you can't patch yet, apply the vendor mitigation from Cisco's advisory: run
no secondary-authentication-server-groupon the affected tunnel groups, or runno tunnel-group-list enablewhere DefaultWEBVPNGroup doesn't use secondary authentication. Treat both as stopgaps, because removing secondary authentication removes a login factor and needs an impact check first.7
Revisit when CISA lists CVE-2026-110264 in KEV, or when Cisco updates advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 with exploitation details.


Comments