CISA Puts Two Exploited Flaws on a 72 Hour Fuse
CISA gave federal agencies three days. On 29 October, it added two actively exploited flaws to its Known Exploited Vulnerabilities catalog. One scores a perfect 10.0. The fix deadline lands on a Sunday.
What Happened?
The first flaw sits in GitLab. An attacker who never logs in can run code on the server by hiding a crafted regular expression inside a CI/CD config file. GitLab shipped fixes on 12 October in versions 19.2.8, 19.3.5 and 19.4.2.
Then comes the twist. The real repair lives in Ruby, which GitLab bundles into its own packages. Run your own Ruby build and the upgrade changes nothing. This is open source dependency risk in its plainest form.
The second flaw hits Cisco. One crafted request makes an ASA or FTD firewall reload and drops the SSL VPN. Firewalls that fall over on a single packet are not new ground, as the PAN-OS bugs that forced firewalls into reboot loops showed.
You upgraded GitLab. Your Ruby may still be open.
The fix for the CI/CD regex flaw lives in the Ruby that GitLab ships inside its own packages, not in GitLab’s application code. Which Ruby your server runs decides whether the upgrade actually closed the hole.
GitLab official packages or official container images
The patched Ruby ships with the release. The upgrade is the whole fix.
ClosedYour own Ruby, a source install, or a custom image
The server keeps its own Ruby. Upgrading GitLab alone leaves the regex engine untouched.
Still exposedor 3.4.12
or 4.0.9 and later
One Linux project upgraded on 22 October and found its server still vulnerable four days later. Check the runtime, not only the release notes.
What Makes This One Different
CISA flagged the two entries differently. GitLab carries a forensic triage requirement. Cisco does not. Translation: regulators expect you to go looking for evidence someone already used the GitLab flaw before you patched it.
CISA has moved at this speed before, including when it confirmed active exploitation of a VMware Aria flaw. Three days is now the pattern, not the exception.
What’s the Impact?
Alpine Linux found out the hard way. An attacker crashed its GitLab workers 8 times, then returned five days later. The project found no proof the attack worked, could not rule it out, and rebuilt the server from scratch. Shadowserver counts over 51,000 exposed Cisco VPN firewalls.
What to hunt for, when nobody has published an IP or a hash
Signals on a self managed GitLab server
- New account, immediate pipeline activity. An account registered and submitting CI configuration within hours.
- Unusual regular expressions in submitted CI config, especially against the CI lint surface.
- Repeated worker crashes. The public incident saw 8 crashes across 2 days, in a crash and retry pattern.
- 502 errors and failed CI jobs clustered in the same window as those crashes.
- Timing probes. Repeated requests with systematic variation in response time.
- A pull of your own container image by an unfamiliar account, which suggests tuning to your exact build.
- Repeat attempts after blocking. The same actor returned 5 days later.
- Post event sweep: unexpected files, repository hooks, SSH keys and running processes.
Signals on an SSL VPN firewall
- Unexplained device reloads on any ASA or FTD terminating remote access SSL VPN.
- Crash and reload history that does not line up with a change window or a known fault.
- Repeated SSL VPN connection attempts and abnormal authentication activity before a reload.
- Availability gaps reported by remote staff that nobody opened a ticket for.
- Config check:
webvpnenabled on any interface. - Config check:
secondary-authentication-server-groupon any tunnel group, includingDefaultWEBVPNGroup. - Escalate any reload you cannot explain to Cisco TAC with the crash file.
Preserve CI job logs, worker crash records and firewall reload history before retention rolls them off. The public incident lost its background job logs and old container filesystem, and that is why its outcome is still recorded as unknown.
How to Avoid This
Three days does not leave room for your whole backlog. It leaves room for a fix-first list.
- Inventory every internet-facing GitLab server and every ASA or FTD device today
- Patch GitLab to 19.2.8, 19.3.5 or 19.4.2, then check the Ruby version separately
- Confirm Ruby 3.3.13, 3.4.12 or 4.0.9 on source installs and custom images
- Move ASA and FTD to a fixed release, because Cisco lists no complete workaround
- Preserve CI logs, worker crash records, and firewall reload history before retention clears them
Indicators of Compromise
Nobody has published one. No IPs, no hashes, no domains, no signatures from the vendors, from CISA, or from the affected project. The triage checklist covers what you can actually hunt for: new accounts submitting odd CI configuration, repeated worker crashes with 502 errors, container image pulls by unfamiliar accounts, and unexplained firewall reloads. Note the blind spot. A successful GitLab exploit does not crash the worker and does not reach your web logs.
Three Days to Patch. Who’s Doing the Counting?
A short deadline rarely fails on patching. It fails on knowing what you own and proving what you fixed.
- Red Teammate checks which exposed instances an attacker can actually reach, so the list starts with real exposure
- Cloud Teammate maps every internet-facing GitLab server and VPN firewall against the fixed version list, runtime included
- SOC Teammate pulls crash records, CI job history, and reload logs into one case before the evidence ages out
- GRC Teammate keeps the record of what was patched and when, ready for whoever asks about the deadline
- Consequential changes stop at a human approval gate, and every action stays logged
