On 29 October 2026 CISA added two more vulnerabilities to its KEV catalogue, the list of flaws with evidence of real-world exploitation. One is GitLab's, the other belongs to Cisco's firewalls. If you run GitLab on your own machines, this one is yours.
What happened
Two entries, published the same day in CISA's alert:
- CVE-2026-97229, in GitLab Community Edition and Enterprise Edition. An integer overflow: an internal counter goes past the largest value the variable can hold, wraps around, and the program carries on with a number that means nothing. It has been doing the rounds in headlines as a maximum-severity flaw.
- CVE-2026-76418, in Cisco Secure Firewall ASA and FTD software. Different pattern: a return value nobody checks, execution continues with a null pointer, and the process hits the floor.
The gap between "it's in the KEV" and "it has a high CVSS" is the whole story: the KEV catalogue only lists flaws with proof that someone is using them out there. It isn't a list of theoretical risk, it's a list of things already happening.
CISA uses the alert to remind everyone of directive BOD 26-04, which makes US federal civilian agencies prioritise by risk: internet-facing assets that hand over full control first, everything else can wait. And it adds a piece almost nobody mentions — the directive also sets out when agencies must check whether someone got in before the patch went on.
Why it matters
That last point is what changes your working day.
A GitLab box is not just another app. Inside it sits the whole source tree, CI variables with deployment credentials, runner tokens, container registry keys, webhooks pointing at production. If somebody had access for fifteen minutes, this afternoon's patch takes nothing back from them. The credentials living in your GitLab still work after you upgrade. That's the bit people skip.
So the sensible order, if you run your own instance:
- Know how many you have. Not the one you use daily: the one from that 2021 project, the staging box somebody exposed "just for a minute" for a demo. That's the one that bites.
- Upgrade, starting with whatever answers from the internet.
- Look before you call it closed: new users or changed permissions, personal access tokens created in recent weeks, SSH and deploy keys added, runners you don't recognise, webhooks pointing somewhere odd, CI jobs edited on branches nobody touches.
- Rotate: CI tokens, deploy keys, runner secrets. Everything a visitor could have read.
With ASA and FTD the logic differs, but the location is worse: it's the perimeter. A firewall that reboots on its own isn't a data incident, it's the VPN going down on a Monday morning with the whole office watching. And if your perimeter patching plan is "we'll look at it in the next maintenance window", somebody else is going to pick the window for you.
What doesn't change
Let's be fair to the story, because it can be told bigger than it is.
A CVE landing in the KEV doesn't mean you are being attacked or that there is a mass campaign. It means exploitation has been observed somewhere. Nor are these two flaws the same calibre: dereferencing a null pointer usually ends in a service crash, not code execution, and lumping it in with the GitLab one confuses two different problems.
CISA doesn't publish indicators of compromise or exploitation detail in these alerts, so the hunt is yours to build with whatever the vendor gives you. And BOD 26-04 binds US federal agencies and nobody else: if you're in Valencia, it's advice, not law. It just happens to be rather good advice.
One more: entering the KEV is almost never the same as a zero day. In most cases the patch has been out for weeks and what failed wasn't the vendor, it was the rollout.
Our take
The KEV has quietly become half the world's patching calendar, and I think it's the best thing to happen to vulnerability management in years. It's the only list that separates "this has an ugly score" from "this is being used". Anyone who has tried to prioritise a report with a thousand findings knows the score alone prioritises nothing.
What I don't like is how it gets consumed. Half of all organisations read the alert, upgrade and mark it done. Patching cuts off the way in; it doesn't evict anyone already inside. On a GitLab box, where the loot is credentials that remain valid, that difference is everything. Which is why the part of BOD 26-04 that forces you to ask "did they already get in?" strikes me as the genuinely new bit of the directive, and the one nobody is discussing.
Now the arguable opinion: a self-hosted GitLab hanging straight off the internet, with no VPN or conditional access in front of it, is a decision that ages badly. If your runners can reach production, your GitLab is production, however the inventory labels it. Treating it as a team wiki is the root error; whichever CVE shows up is just the invoice.
This is exactly what we find whenever we take over someone's infrastructure: the problem is almost never that they can't patch, it's that nobody holds the full list of what's exposed and since when. And a list that doesn't exist doesn't get patched.
Any questions, tell me and we'll go through it. All the best, Vicente.