The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added GitLab and Cisco vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, Security Affairs reported this week. The news is not the CVE list itself — it is the deadlines that come attached to it.
Why the deadline is the story
KEV is CISA's running register of flaws that have been seen exploited in the wild. Adding a vulnerability does more than flag it: under CISA's Binding Operational Directive 22-01, federal civilian agencies must remediate listed flaws within 21 days (three weeks) by default, or within 14 days where CISA assigns a ransomware-associated deadline. Each entry carries a specific due date in the catalog.
That obligation binds U.S. federal agencies, not organisations elsewhere. But the practical effect travels well beyond that scope. For administrators outside the federal estate, KEV membership functions as an external verdict that a flaw is not theoretical — it is being used. Many security teams and managed service providers treat it as a baseline service-level target: someone else's binding deadline becomes your own patching benchmark, because the exploitation it reflects does not stop at a jurisdictional border.
What was added
Security Affairs names CVE-2026-97229 as the headline GitLab entry in the batch and describes it as a critical flaw that could allow attackers to execute code. For anyone running GitLab in production, that combination of critical severity and demonstrated exploitation is exactly the profile KEV exists to surface.
The report also indicates at least one Cisco flaw among the new additions, but does not enumerate every CVE in the batch. Administrators should therefore go straight to CISA's official KEV catalog — the authoritative record — to confirm the complete set of additions, verify individual CVE identifiers and severity descriptions against the primary source, and check the per-CVE due dates recorded against each one.
Administrators of both self-hosted and vendor-managed instances should verify their versions against the vendor advisories.
What to do now
- Check your inventory. Pull the full KEV additions list from CISA's catalog and match every CVE, including its stated due date, against your GitLab and Cisco estate.
- Work backwards from the remediation window. Treat the applicable deadline — 21 days by default, 14 days where a ransomware association applies — as your hard stop, not your target date.
- Patch or apply vendor mitigations. Prioritise internet-facing instances and any service holding privileged tokens or CI/CD credentials.
- Review logs for indicators of compromise. KEV membership means exploitation has been observed; assume reconnaissance is plausible and check authentication, pipeline, and admin-panel activity from the relevant window.
- Confirm coverage for managed deployments. If a provider runs the platform on your behalf, get written confirmation that the patched version is live and ask when it was applied.
The broader point
The incident is a useful reminder of how threat-intel feeds now function as de facto standards. A catalog built for one government's compliance regime ends up shaping patch priorities for enterprises, managed service providers, and open-source operators worldwide — not because it compels them, but because it converts "known exploited" into a dated, public, auditable commitment.
For IT professionals anywhere, the operative question is simple: if a flaw has made the KEV list, your remediation clock has effectively started, whether or not your regulator has said so.
Source: Security Affairs. CVE identifiers and due dates should be confirmed against CISA's official KEV catalog before acting.
Security Affairs 本周報道，美國網絡安全及基礎設施安全局（CISA）已將 GitLab 及 Cisco 的漏洞列入其已知被利用漏洞（KEV）目錄。新聞焦點不在於 CVE 清單本身——而在於隨之而來的限期。
為何限期才是報導重點
KEV 是 CISA 持續更新的漏洞登記冊，收錄曾在真實環境中被利用的漏洞。將漏洞列入該目錄，意義遠不止是作出標示：根據 CISA 的《具有約束力的運作指令 22-01》（Binding Operational Directive 22-01），聯邦民用機構須在預設21 日（三星期）內修補已列明的漏洞；若 CISA 指定與勒索軟件相關的限期，則須在 14 日內完成。目錄中每一條目均載有明確的到期日。
此項規定約束的是美國聯邦政府機構，而非其他地區的組織。然而其實際影響遠超此範圍。對於聯邦體系以外的管理員而言，列入 KEV 相當於一項外部裁定，證明該漏洞並非紙上談兵——它確實正被利用。許多安全團隊及託管服務供應商（managed service provider）將其視為基本的服務水平目標：別人的具約束力限期，成為你自己的修補基準，因為其所反映的利用行為不會止步於司法管轄邊界。
新增了甚麼
Security Affairs 將 CVE-2026-97229 指為該批次中焦點的 GitLab 條目，並描述其為嚴重（critical）級別漏洞，攻擊者可能藉此執行代碼。對任何在生產環境運行 GitLab 的管理員而言，嚴重級別加上已有實際利用證據，正是 KEV 目錄旨在揭示的漏洞特徵。
報道亦指出新增條目中至少包含一個 Cisco 漏洞，但未逐一列出該批次中的所有 CVE。因此，管理員應直接查閱 CISA 官方 KEV 目錄——即權威紀錄——以確認完整的新增清單、對照一手來源核實各個 CVE 編號及嚴重級別描述，並查閱各 CVE 對應的到期日。
自建（self-hosted）及由供應商託管的實例管理員，均應按照供應商安全通告核實其版本。
現在應採取的行動
- 盤點現有清單。 從 CISA 目錄取得完整的 KEV 新增漏洞清單，逐一將每個 CVE（包括其列明的到期日）與你旗下的 GitLab 及 Cisco 環境作對照。
- 由修補限期向前倒推。 將適用的限期——預設 21 日，涉及勒索軟件關聯者為 14 日——視為不可逾越的硬性限期，而非目標日期。
- 修補漏洞或套用供應商緩解措施。 優先處理對外連接互聯網的實例，以及任何持有高權限 token 或 CI/CD 憑證的服務。
- 檢視日誌中有無入侵指標（indicators of compromise）。 列入 KEV 意味著已觀察到利用行為；應假設偵察活動極有可能發生，並檢查相關時段內的驗證、pipeline 及管理面板活動。
- 確認託管部署的修補覆蓋情況。 若由服務供應商代為運行平台，須取得書面確認，證明已修補版本已正式上線，並查問修補的實施日期。
更宏觀的啟示
此事件有力提醒我們，威脅情報（threat intelligence）供應源如今已如何演變成事實上的標準。一個為單一政府合規制度而設的目錄，最終卻左右了全球企業、託管服務供應商及開源營運者的修補優先次序——並非因為它對這些組織具有強制力，而是因為它將「已知被利用」轉化為一項載明日期、公開透明、可供審計的承諾。
對於任何地方的 IT 專業人士而言，關鍵問題很簡單：一旦某個漏洞上了 KEV 清單，你的修補倒數時鐘實際上就已經啟動——不論監管機構有沒有這樣說。
來源：Security Affairs。CVE 編號及到期日須先對照 CISA 官方 KEV 目錄核實，方可採取行動。