The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday added two actively exploited vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, The Hacker News reported — a critical remote code execution (RCE) bug in GitLab and a denial-of-service flaw affecting Cisco firewall products. Under CISA's Binding Operational Directive (BOD) 22-01, newly listed flaws typically carry a two-week remediation window for federal civilian executive branch agencies.
The two flaws on the list
The higher-priority entry is CVE-2026-97229, an integer overflow or wraparound vulnerability in GitLab Community Edition and Enterprise Edition carrying a maximum CVSS score of 10.0. Under BOD 22-01, federal civilian executive branch agencies must remediate the flaw within the standard two-week window the directive sets for KEV entries.
The second entry is a denial-of-service flaw affecting Cisco firewall products. CISA's listing does not specify a CVSS score for the Cisco flaw — which only sharpens the argument security teams repeatedly make about these listings: KEV inclusion is driven by observed exploitation, not by severity score alone. A bug that attackers are demonstrably using can warrant the same urgency as a theoretical worst-case vulnerability, whatever its score.
Why GitLab operators should act first
For organisations running self-managed GitLab, the remediation burden falls squarely on the operator — there is no cloud-hosted intermediary applying patches on your behalf. That matters because an internet-facing GitLab instance sits at the intersection of high-value assets: source repositories, CI runners, and pipeline secrets can all be exposed in a single compromise. An RCE rated 10.0 against such a surface is about as serious as vulnerability management gets.
The practical sequence is straightforward: patch GitLab first, then address the Cisco denial-of-service flaw — either through an official fix or through compensating controls that restrict access to the firewall's management plane.
What the deadline actually means
BOD 22-01 applies to U.S. federal agencies, not to private-sector organisations. Companies are not legally bound by the two-week deadline. In practice, though, many security teams treat KEV remediation timelines as an informal benchmark — a publicly stated window against which their own patch cycles are measured, and increasingly a talking point in customer questionnaires and supply-chain assessments.
That benchmark framing is useful: it converts a vague "high priority" into a concrete, dated commitment.
The takeaway
Prioritise CVE-2026-97229, confirm that any self-managed GitLab instances are running the fixed release from the vendor advisory, and verify that Cisco firewall management interfaces are either patched or unreachable from untrusted networks. For teams that cannot patch immediately, documented compensating controls and a tracked remediation date are the minimum acceptable position.
The broader lesson is one of accuracy over convenience: a threat list is only as useful as the speed with which it is acted upon. The two-week window typically attached to a new KEV entry is not a long one — and for teams responsible for both GitLab and perimeter firewall infrastructure, it is a deadline worth treating as real regardless of whether it is legally binding in your jurisdiction.
Source: The Hacker News
據 The Hacker News 報道，美國網絡安全和基礎設施安全局（CISA）於星期四將兩個正在被活躍利用的漏洞加入其「已知被利用漏洞」（Known Exploited Vulnerabilities，KEV）目錄——分別是 GitLab 的嚴重遠端代碼執行（RCE）漏洞，以及影響 Cisco 防火牆產品的拒絕服務漏洞。根據 CISA 的《具約束力操作指令》（Binding Operational Directive，BOD）22-01，新列入名單的漏洞通常須在兩星期內完成修補，適用於聯邦民事行政分支機構。
名單上的兩個漏洞
優先級較高的是 CVE-2026-97229，這是 GitLab Community Edition 和 Enterprise Edition 中的一個整數溢出（integer overflow）或回繞（wraparound）漏洞，CVSS 評分達最高的 10.0 分。根據 BOD 22-01，聯邦民事行政分支機構須在指令為 KEV 條目設定的標準兩星期期限內完成修補。
第二個條目是影響 Cisco 防火牆產品的拒絕服務漏洞。CISA 的名單並未列明該 Cisco 漏洞的 CVSS 評分——這反而突顯了安全團隊對這類名單一再提出的論點：KEV 的收錄取決於實際觀察到的利用情況，而非單憑嚴重性評分。 一個攻擊者確確實實正在使用的漏洞，無論其評分如何，其處理緊迫性可與理論上最嚴重的漏洞相提並論。
為何 GitLab 營運者應優先處理
對於運行自行託管（self-managed）GitLab 的機構而言，修補責任完全落在營運者身上——沒有雲端託管的中介方會代為套用修補程式。這點至關重要，因為一個面向互聯網的 GitLab 實例正處於高價值資產的交匯點：原始碼儲存庫（source repositories）、CI runners 及 pipeline secrets 都可能在一宗入侵事件中全部外洩。針對此類攻擊面的 10.0 分 RCE，在漏洞管理領域已屬最嚴重等級。
實際處理次序相當直接：先修補 GitLab，再處理 Cisco 的拒絕服務漏洞——可以透過官方修復方案，亦可以透過限制防火牆管理平面（management plane）存取的補償性控制措施（compensating controls）來應對。
限期實際代表什麼
BOD 22-01 適用於美國聯邦機構，而非私營機構。企業在法律上並不受此兩星期限期約束。然而在實務上，不少安全團隊已將 KEV 修補時限視為非正式的基準——一個公開聲明的期限，用以衡量自身的修補周期，並且日益成為客戶問卷調查及供應鏈評估中的討論要點。
這種基準框架相當有用：它將模糊的「高優先級」轉化為具體、有明確日期的承諾。
結論
優先處理 CVE-2026-97229，確認所有自行託管的 GitLab 實例已運行廠商公告所指明的已修復版本，並核實 Cisco 防火牆管理介面或已完成修補，或無法從不受信任的網絡（untrusted networks）存取。對於無法即時修補的團隊，具備文件記錄的補償性控制措施及已納入追蹤的修補日期，是可接受的最低要求。
對 IT 界更廣泛的啟示在於準確性優於方便：一份威脅名單的價值，取決於應對行動的速度。新 KEV 條目通常附帶的兩星期窗口並不算長——對於同時負責 GitLab 及邊界防火牆基礎設施的團隊而言，即使該限期在貴司法管轄區並不具法律約束力，也應視之為真實的期限予以重視。