如果團隊管理 NetScaler，今天應先確認哪些節點啟用了 SAML、運行哪一條版本分支，再安排修補與調查。只把工單寫成「升級 NetScaler」會漏掉備援節點、SPA Hybrid 使用的實例，以及升級後是否仍能完成登入。
本文整理截至台北時間 2026 年 10 月 5 日的官方資料與工程建議；沒有在 NetScaler 設備上實測，也不假設讀者環境使用此產品。
今日的新進展是已知利用，原公告在兩天前
Citrix 公告 CTX697174將 CVE-2026-88779 定義為記憶體溢位造成的阻斷服務（DoS），CVSS v4 基礎分數為 8.7，前提為 SAML SP 或 IdP。公告變更紀錄寫的是 10 月 3 日（PST）。公開描述支持的是可用性影響，不能把它改寫成已證實的遠端程式碼執行漏洞。
CISA 官方 KEV JSON的 2026.10.04 版本於 10 月 4 日 18:52:56 UTC 發布，換算台北為 10 月 5 日 02:52:56。該 CVE 的 dateAdded 是 10 月 4 日，dueDate 是 10 月 7 日，forensicTriage 為 Yes，勒索軟體使用狀態則是 Unknown。資料集發布時間與 CVE 的新增日期是不同欄位；不要替該筆條目推定更精確的加入秒數。
KEV 表示 CISA 已確認存在利用，不表示每台部署都遭到攻擊；Unknown 也不代表已證明沒有勒索軟體利用。CISA 對 BOD 26-04 的官方說明指出，指令要求聯邦機關依風險安排修補。10 月 7 日應放在受該指令規範的機關情境下理解，不能宣稱是所有企業或個人的法定期限。
我的判斷是：對符合條件的自管部署，KEV 應把這項工作從一般版本維護提高到需有人負責的處置事項。實際排程仍要把入口暴露、業務可用性、備援與調查保全一起考慮，不能只看分數。
配置、分支與管理責任必須一起核對
依 CTX697174，先在受控的配置檢視中找 add authentication samlAction（SP）或 add authentication samlIdPProfile（IdP）。這兩段文字是辨識配置的線索，不是要求新增或變更認證設定的指令。
官方受影響／修補邊界如下，須使用同分支的修正版本或後續版本：
- 一般 14.1：低於
14.1-73.41；升至14.1-73.41或以上。 - 一般 13.1：低於
13.1-64.28；升至該 13.1 分支的修正版或以上。 - 14.1 FIPS：低於
14.1-73.41 FIPS；使用 FIPS 修正版或以上。 - 13.1 FIPS／NDcPP：低於
13.1-37.282；使用對應分支修正版或以上。
公告涵蓋自管 ADC／Gateway，包含使用 NetScaler 的 Secure Private Access Hybrid；Citrix 管理的雲端服務與 Adaptive Authentication 由廠商更新。託管責任要按實際服務判斷，不能因為系統「在雲端」就直接排除自管實例。以上範圍及版本均以同份官方公告為依據。
工程盤點建議是一台節點一筆紀錄，記下資產 ID、完整 build、分支、SAML 角色、是否對外、HA 角色、管理者及受影響登入流程。配置匯出可能含有敏感資料，應放進既有受限的處置空間，不貼到公開工單。
找不到配置或無法確認 build，狀態應是「待確認」，不能標記「不受影響」。 這是一條本文建議的停止規則；只有取得可查證的條件與版本，才足以關閉適用性判斷。
修補工單與調查工單需要不同證據
先確認適用條件
資產、SAML、分支、暴露及管理責任。資訊不足時保持待確認。
修補軌
核對 SAML 與版本分支
每個節點升級，再驗證正常登入
調查軌
保存時序與可取得的證據
分析異常，明列證據範圍與缺口
各自留證據，再覆核
升級完成不代表修補前沒有事件；未發現證據不代表從未遭利用。
KEV 的 forensicTriage: Yes 讓團隊有理由同步啟動調查分流。CISA 的官方說明也要求在指定情境檢查修補前是否已遭入侵；它沒有在這筆 JSON 裡公開完整攻擊操作或能證明安全的單一指標。本文因此不自行補造 exploit、IOC 或「搜尋某字串即可排除入侵」的結論。
以下是處置工作建議，並非 Citrix 對每個環境都保證可行的操作程序：
升級前留下能還原時序的紀錄
維運者先記錄時間與時區、節點／build、HA 健康、近期服務中斷及認證錯誤，並保存可取得的相關日誌與配置快照。若已有事故跡象，讓應變負責人決定哪些揮發性證據應在重啟前採集，協調隔離、保全與服務復原的順序。不要為了取得完美證據而無限延後處理正在中斷的服務；把風險決策及原因留下來。
備份與回復程序也應確認能用，但退回受影響版本不能成為長期解法。若相容性問題迫使回復，工單必須重新打開暴露風險，由負責人評估可用的替代服務、限制暴露方式與再次升級時程。本文沒有驗證任何特定 WAF 規則或停用設定能完整替代補丁。
升級後驗證登入路徑與每個節點
版本查核應涵蓋主用、備援及其他會接流量的節點，保留各節點的完整 build 證據。接著用核准的測試帳號走一次正常 SAML 登入、回到目標應用程式、登出並重新登入；視環境檢查 HA 切換與服務健康。這些是正常使用情境的回歸驗證，不是在正式設備重現攻擊。
驗收可以分成兩個結果：版本符合官方分支邊界，與業務登入／服務流程通過。任何一項失敗，都不能只因為維護視窗結束便宣告修補完成。先前的憑證驗證除錯文章也說明了類似邊界：連線成功與信任條件通過，需要各自的證據。
調查結論保留不確定性
安全負責人把異常時序、可取得的日誌、資產暴露與廠商支援回覆串起來，決定是否升級成正式事件應變。可以記錄「在所檢視的資料範圍內未發現證據」，不能將它寫成「從未遭到利用」。DoS 的官方影響描述也不等於這次環境完全沒有其他事件；但同樣不能拿 KEV 當作這台設備已被入侵的證據。
這與展示設備事件應變的共通點，是把恢復服務、保留證據與責任交接分開。修補關閉的是已知版本缺陷，調查回答的是修補前發生過什麼。
今天先產出一份有負責人的適用性清單
下一步是請維運與安全窗口共同填完節點清單：哪些已確認不符合條件、哪些需要升級、哪些證據仍缺。對適用節點，同時指定修補窗口、正常登入回歸的負責人，以及調查結果的覆核者。只有配置、版本、驗證與調查狀態都有可追溯紀錄，這項 KEV 才不會在「更新完成」四個字裡被過早結案。