威脅分析
VPN 漏洞為什麼補不完
多數公司處理 VPN 漏洞的流程長得都差不多：廠商發公告、資訊部門評估影響、排一個離峰的維護時段、停機更新、重開機、回報完成。這個流程本身沒有問題，它唯一的假設是「時間是我們的」——而這個假設，在遠端存取設備上不成立。
真正該問的不是「我們補得夠不夠快」，而是「為什麼這類設備每年都有新的一批」。這篇文章用 CISA 已知被利用漏洞目錄（KEV）的實際資料回答，用的是 2026 年 8 月 21 日那一版，全目錄 1674 筆。
看完你應該能回答三個問題：這類設備的漏洞量級是多少、為什麼修補流程結構上就慢一步、以及補丁裝完之後還有哪些事沒做完。
VPN 漏洞在 KEV 目錄裡是什麼量級
KEV 收的不是「理論上有風險」的漏洞，是已經有證據顯示被實際利用的漏洞。它的存在依據是 BOD 22-01，美國聯邦機關必須在目錄給的期限內完成處理。所以這份清單可以當成一份「已經在被打」的名單來讀。
在 1674 筆裡，屬於遠端存取與邊界閘道設備的有 93 筆——SSL VPN 閘道、遠端存取閘道，以及帶 VPN 功能的邊界防火牆。這 93 筆來自九家廠商：
| 廠商 | 筆數 |
|---|---|
| Cisco | 16 |
| Fortinet | 15 |
| Ivanti | 14 |
| SonicWall | 13 |
| Palo Alto Networks | 12 |
| Citrix | 11 |
| F5 | 7 |
| Check Point | 3 |
| Array Networks | 2 |
Ivanti 那一列包含併購前以 Pulse Secure 名義掛號的條目。同一份目錄總共收錄了 278 家廠商。也就是說，佔比 5.6% 的條目，來自佔比 3.2% 的廠商。
更值得注意的是勒索軟體那一欄。KEV 會標記某個漏洞是否曾被用於勒索軟體行動：全目錄 1674 筆裡有 352 筆（21%）被標記；而這 93 筆裡有 50 筆（54%） 被標記。同一份資料、同一個判準，比例高出約 2.5 倍。
- 曾用於勒索軟體行動
- 其餘條目
圖說文字版
CISA 已知被利用漏洞目錄裡的遠端存取設備條目，逐年排開後是一條平的線，不是一次意外。
每年新增筆數（括號內為其中曾用於勒索軟體行動者）
- 2021 年：19 筆（11 筆）。
- 2022 年：21 筆（11 筆）。
- 2023 年：7 筆（5 筆）。
- 2024 年：18 筆（11 筆）。
- 2025 年：18 筆（8 筆）。
- 2026 年至八月：10 筆（4 筆）。
要看出來的事
- 六年合計 93 筆，其中 50 筆被標記為曾用於勒索軟體行動，超過一半。
- 這 93 筆集中在九家廠商；同一份目錄總共 1674 筆、來自 278 家廠商。
- 2021 年是目錄首發年，一次補登了先前的歷史條目；2026 年只統計到八月。
- 除了 2023 年之外，每年都落在十幾到二十筆之間——供給量是穩定的。
一個誠實的但書：這 93 筆是依廠商與產品名稱歸類的，邊界怎麼畫會讓數字增減幾筆——把帶 VPN 功能的防火牆算不算進來，結果就會不同。但多算少算三五筆，不會改變上面兩個比例的量級。
為什麼是這類設備：它必須先對全世界回應
VPN 漏洞集中在這類產品，跟哪一家廠商的工程品質沒有太大關係。原因有三個，而三個都是這個「位置」本身的性質。
第一，它必須對全世界回應。 員工在外面要連得進來，就代表這台設備得在公網上收未經驗證的請求——這在 MITRE ATT&CK 裡就是外部遠端服務（T1133）。你無法用防火牆規則把它藏起來，因為它就是那道防火牆的入口。
第二，它的攻擊面在驗證之前。 一台設備要驗證你是誰，就得先解析你送來的東西：TLS 交握、HTTP 標頭、登入表單、入口網頁的參數。這些程式碼在「確認你是誰」之前就跑了，所以任何一個錯誤都是利用對外應用程式（T1190）的機會。93 筆裡光是名稱帶「驗證繞過」「驗證不當」「授權缺漏」的就有 17 筆——這些漏洞的共通點是，攻擊者根本不需要帳號密碼，所以 MFA 也擋不到。
第三，它是信任錨點。 這台設備握有所有遠端使用者的 session、設定檔、有時候還有可還原的憑據。打下它不是拿到一個立足點，是一次拿到整份名單。
這三點加起來的意思是：換一家廠商不會改變這個結構。它會改變你未來要追哪一組公告，不會改變你有一台必須對全世界回應、且知道所有人是誰的設備。
補丁為什麼永遠慢一步
因為兩個時鐘不是同時起跑的。
攻擊者這一側的時鐘，從「這個漏洞可以被利用」開始走——這個時間點經常早於任何公告，也就是零日漏洞的情況。你這一側的時鐘，從「公告送到你眼前」才開始走，後面還接著確認版本、排維護時段、停機、重開。
- 攻擊者這一側的時程
- 你這一側的修補流程
- 曝險窗口
圖說文字版
攻擊者的時程與你的修補流程畫在同一條軸上，兩邊共用「廠商公告」這一個點，但起訖不同。
上排：攻擊者這一側
- 漏洞已可被利用，這個時間點可能早於公告。
- 公告後數小時，全網開始掃描。
- 取得立足點；到這一步之後，這個漏洞就用不到了。
下排：你這一側
- 公告出來，你看到了。
- 確認影響範圍與版本。
- 排進維護時段。
- 停機、更新、重開完成。
中間的紅色區塊
- 曝險窗口從「漏洞可被利用」延伸到「你更新完成」。
- 它比公告更早開始，也比公告更晚結束。
- CVE-2025-5777 被列入 KEV 的隔天就是聯邦機關的修補期限；同一份目錄一般給 21 天。
- 窗口的長度不是你決定的，但窗口裡有多少東西可以被碰到，是你決定的。
KEV 給的修補期限可以看出主管機關怎麼看待這段落差。目錄的常態期限是 21 天，但這 93 筆裡有 23 筆的期限落在 7 天以內：
| 漏洞編號 | 產品 | 列入 → 期限 |
|---|---|---|
| CVE-2025-5777 | Citrix NetScaler | 2025-07-10 → 07-11 |
| CVE-2025-0282 | Ivanti Connect Secure | 2025-01-08 → 01-15 |
| CVE-2024-3400 | Palo Alto PAN-OS | 2024-04-12 → 04-19 |
第一列不是筆誤：列入目錄的隔天就是期限。
而你做不到 7 天的原因，通常不是懶惰或人手不足，是這台設備一停機，所有在外面工作的人同時斷線。能不能修，取決於能不能停；而 VPN 閘道正好是全公司最不能停的那一台。 修補管理的排序取捨在 NIST SP 800-40 Rev. 4 有完整討論，但它也解決不了這個矛盾——那是架構造成的，不是流程造成的。
補完之後還是被打進來：CitrixBleed 的教訓
裝完補丁不等於事情結束，這一點有官方版本的證據。
CVE-2023-4966（俗稱 CitrixBleed）是一個越界讀取漏洞：攻擊者能讀到設備記憶體裡的內容，其中包含合法使用者的 session token。拿到 token 之後，攻擊者直接接手一個已經通過驗證的 session——不需要帳號、不需要密碼、也不需要 MFA 的一次性碼，也就是 ATT&CK 的竊取 Web session cookie（T1539）。
CISA 與多國機構在 AA23-325A 這份公告裡記錄了 LockBit 3.0 的附屬組織如何用這個漏洞繞過密碼與 MFA、接管使用者 session。而 KEV 對這一筆的「必要動作」欄位寫的不是「套用更新」，是套用更新，並終止所有 active 與 persistent session。
- 補丁修得回
- 補丁修不回
- 必須另外執行的動作
圖說文字版
補丁能修的是程式，不是漏洞開著的那段時間裡已經被拿走的東西。
左欄：補丁修得回
- 程式裡越界讀寫的那段錯誤。
- 讓驗證被繞過的那段邏輯。
右欄：補丁修不回
- 已經外流的 session token。
- 已經被讀走的帳號與密碼。
- 已經植入的持續性後門。
- 已經匯出的設定檔與使用者清單。
底部一列
- CISA 對 CVE-2023-4966 的必要動作不只是套用更新，還包括終止所有 active 與 persistent session。
- 也就是說，官方認定「補完就結束了」是錯的。
所以事件處理的預設假設要反過來：對這類設備而言，「已修補」只代表窗口關了，不代表窗口期間沒有東西被帶走。這也是為什麼 session 輪替、憑據更換與入侵跡象比對，必須寫進修補作業程序本身，而不是等到出事才想。攻擊者拿到憑據之後會做什麼，勒索軟體入侵途徑那篇拆得比較細。
一台設備被打下來，為什麼等於整個內網
因為閘道模型的設計就是這樣：通過驗證之後，設備發給你一個內網位址，接下來你能碰到什麼，由網段決定，不由身分決定。
這解釋了一個看起來過度反應的官方動作。2024 年 1 月，CISA 針對 Ivanti Connect Secure 與 Policy Secure 的漏洞發出緊急指令 ED 24-01，要求聯邦機關在 2 月 2 日晚間之前把所有這類設備從網路上斷開，並且在重新上線前走完一整套指定程序。
主管機關的判斷是「先拔線」而不是「先修補」。這個判斷只有在一種情況下合理：這台設備通往的東西，多到不值得為了維持它的可用性而承擔風險。
換句話說，把 VPN 漏洞當成「入口的問題」會低估它。它是三件事疊在一起——一個必須公開的入口、一個握有所有人身分的信任錨點、一條通往整個內網的路。三種架構在這一點上的差異整理在傳統 VPN、閘道式 ZTNA 與 SDP 架構比較；讓服務對未驗證請求完全不回應的機制，則在軟體定義邊界（SDP）是什麼、怎麼運作。
修補之外，可以現在就做的五件事
修補該做，而且要繼續做。以下五件是修補之外、而且不需要採購就能開始的：
- 把管理介面從公網下線。 KEV 裡有數筆條目針對的是設備的管理介面而不是 VPN 服務本身。管理介面沒有任何理由對全世界開著。
- 拿 KEV 對一次自己的設備清單與版本，而不是等廠商電子報。國內的通報與情資可以並看 TWCERT/CC。
- 把「終止所有 session、輪替憑據與金鑰」寫進修補作業程序，讓它跟套用更新是同一張工單，而不是事後補救。
- 盤點還有什麼跟 VPN 一樣對全世界開著。 通常不只一台，做法見你的公司在公網上暴露了什麼：攻擊面盤點。
- 問一個問題：使用者通過驗證之後，實際上能連到幾台主機。 如果答案是「整個網段」，那你目前所有的努力都花在縮短曝險窗口的長度，而完全沒有處理窗口裡的損失範圍。
第 5 項的答案若不理想，那要處理的是架構而不是修補速度——VPN 替代方案怎麼選、怎麼汰換談的就是這條路怎麼走，以及並行期該怎麼設計。
名詞對照與延伸閱讀
| 名詞 | 一句話解釋 | 出處 |
|---|---|---|
| 已知被利用漏洞目錄 | 已確認遭實際攻擊利用的漏洞清單 | CISA KEV |
| BOD 22-01 | 要求聯邦機關依 KEV 期限處理的指令 | CISA BOD 22-01 |
| 外部遠端服務 | 對外開放供遠端登入的服務 | MITRE ATT&CK T1133 |
| 利用對外應用程式 | 攻擊對外服務的已知漏洞入侵 | MITRE ATT&CK T1190 |
| 驗證繞過 | 不必通過登入即可取得存取 | CWE-287 |
| 零日漏洞 | 修補釋出前就已被利用的漏洞 | Zero-day vulnerability |
| 修補管理 | 決定何時、依什麼順序套用更新 | NIST SP 800-40 Rev. 4 |
| 越界讀取 | 讀到配置範圍以外的記憶體內容 | CWE-125 |
| session token | 代表已登入狀態的憑證字串 | Session hijacking |
| 竊取 Web session cookie | 拿走 cookie 直接接手已驗證的連線 | MITRE ATT&CK T1539 |
| 多因素驗證（MFA） | 密碼之外再加一道驗證因子 | NIST SP 800-63B |
| 緊急指令 ED 24-01 | 要求聯邦機關斷開特定設備的指令 | CISA ED 24-01 |
| 橫向移動 | 攻擊者在內網從一台主機擴散到下一台 | MITRE ATT&CK TA0008 |
| 攻擊面 | 所有可被外部觸及的入口總和 | Attack surface |
| 零信任架構 | 不以網路位置作為信任依據的架構 | 何謂零信任架構 |
上面的數字都可以自己重算：KEV 目錄有公開的 JSON 版本，把廠商與產品欄位篩一次就能得到自家設備清單對應的條目。若需要針對特定環境評估這段曝險窗口實際能被走到哪一步，歡迎與我們聯絡。