GitLab 的十月緊急修補，值得放進變更單的第一個細節是版本號。官方 10 月 12 日公告目前列出 19.4.2、19.3.5、19.2.8；19.3.4 在啟用 Ona 整合時有 merge request 頁面問題，後續由 19.3.5 修正。只照早期新聞填升級目標，可能讓修補工單過早結案。

我會把這次驗收拆成版本、工作流、事件調查三份結果。套件裝完可以完成第一項的一部分；另外兩項仍需要各自的證據。以下是工程建議，本文未部署 GitLab、重現漏洞或執行升級。查核截至 2026 年 10 月 13 日台北上午。

2026 年 10 月 21 日另有 CVE-2026-110264 緊急修補，受影響版本與目標已擴大。新的 GitLab regex RCE 日誌查核整理該輪修補界線，以及崩潰請求可能缺少 Rails 紀錄、需交叉核對 Workhorse 與 Puma 的調查限制。以下保留 10 月 12 日公告的驗收脈絡，不能用它的版本號判定後續漏洞已修補。

RCE 與 Duo 注入需要不同的盤點問題

依同份公告，CVE-2026-97229 為 CVSS 10.0 的 CI/CD 正規表示式編譯器問題，特定條件下可讓未登入使用者執行伺服器程式碼。CE／EE 受影響範圍為：

  • 19.2 起、低於 19.2.8
  • 19.3 起、低於 19.3.5
  • 19.4 起、低於 19.4.2

CVE-2026-96893 則是 EE 的 Duo 提示注入：已登入使用者可能使非預期指令歸屬到其他使用者。範圍從 19.1 起、低於 19.2.8，另含上述 19.3、19.4 區間。公告沒有宣稱這兩項已遭實際攻擊；GitLab.com 已更新，Dedicated 客戶不需動作。

這個差別會改變盤點方式。RCE 工單要先找伺服器版本與可達路徑，不能用「我們沒有開 AI」排除。Duo 的盤點則要多問誰能提供內容、誰批准工具動作，以及執行時套用誰的權限。把兩者合寫成「AI 導致遠端入侵」，會讓負責人沿著錯誤方向找補償控制。

我建議資產清單每筆留下版本來源、部署型態、對外入口與負責人。未知欄位直接標成待查。由某個反向代理入口無法連線，只能證明該條路徑當時不可達，不能替所有內網入口或另一套測試站簽結。

修補目標必須與升級路徑一起審

官方升級路徑文件要求按必要停靠版本前進，並在下一站前完成背景遷移。這表示「目標版本正確」與「抵達方式可用」是兩個判斷。特別是落後多個版本的站台，不適合直接拿最新修補號拼出一條套件指令。

變更單可以用四行完成最小交接：目前版本及查核時間、目標版本、必要停靠點、每站遷移完成的證據位置。這是本文建議的紀錄格式，並非 GitLab 內建報表。維護者應依自己的安裝方法，從官方升級入口選擇程序。

我也會要求同一張單留下公告的查核時間。收到新的修補修訂時，既有核准者應能看出目標有沒有變，不必重讀整段聊天紀錄。版本被改過卻沒有更新驗收清單，會形成「部署做對、審核依據過期」的落差。

如果資產有多個節點，驗收紀錄也應逐一對應節點，避免只查到其中一台的版本。排程交接時，把尚未更新的節點與仍可接收流量的入口寫出來，讓後續值班者能分辨正在進行的維護與漏網部署。這是本文建議的盤點粒度，實際更新順序仍須依部署文件決定。

停止規則：無法確認必要遷移完成，就不進入下一個升級停靠點。 緊急程度可以改變排程優先序，不能補出不存在的完成證據。

備份成功仍要回答，失敗時能回到哪裡

GitLab 備份文件提醒，設定檔、金鑰及特定安裝方式的物件儲存需要另外處理。備份工作顯示成功時，維護者仍要確認實際包含哪些資料，不能由壓縮檔存在推論整套服務可還原。

我的建議是把回復責任指定到人，並記下最後可用的還原驗證日期。沒有驗證過，就寫未驗證；不要在緊急工單上臨時把假設升格成承諾。若現場已有還原演練，也要確認演練對應的安裝型態與目前一致。

回復計畫還應區分服務恢復與安全處置。恢復到舊版本可能同時恢復原本的漏洞暴露，因此回復後的網路限制、使用者通知與再次修補時點，也應有負責人。這是風險取捨，無法用一句「有備份可回滾」結束討論。

正常功能與拒絕行為都要留下結果

我建議在隔離測試專案做工作流驗收，用團隊自己定義的低權限帳號與無敏感資料，確認登入、讀取 repository、一般 pipeline 和 merge request 頁面仍正常。啟用 Ona 的部署，應特別把整合開啟時的頁面放入清單。

若某項功能原先就未使用，可以註明不適用並留下原因；測試環境缺少整合憑證則應記為未測，兩者不能合併成通過。這能避免日後新增功能時，把歷史維護工單誤當成完整覆蓋。

權限驗收則從預期被拒絕的動作開始：低權限帳號是否仍無法操作受保護資源？審核者能否從紀錄辨認提出要求與執行動作的身分？若用到 Agent，輸入內容與批准紀錄是否有清楚的對應？這些是一般回歸檢查，不能當作特定 CVE 已成功阻擋的證明。

本站的 Harness 控制面提供工具授權與執行紀錄的設計背景；在這次維護中，範圍可以縮到一個可交付結果：每個關鍵工作流列出操作者、預期、觀察與時間，失敗項附追蹤工單，避免只有一張首頁截圖。

最後，把「已安裝修補」與「沒有遭入侵」分開簽核。前者需要版本和部署證據；後者若需判斷，必須另定調查範圍與資料來源。今天能立即做的事，是在現有修補單補上版本查核時間、回復負責人及工作流驗收結果，讓下一位值班工程師知道哪些已完成，哪些仍待確認。