ServiceNow AI平臺爆出RCE漏洞
ServiceNow AI Platform 的 CVE-2026-6875，是一個 CVSS v4.0 達 9.5 分的遠端程式碼執行漏洞。問題出在 GlideRecord 查詢API會處理可執行的 JavaScript，加上指令碼沙箱存在逃逸路徑；未通過身分驗證的攻擊者在特定情境下，可突破存取限制、讀取資料表、建立管理員帳號，甚至透過已連線的 MID Server 執行 Shell 指令。這不是單純資料外洩，而是可能一路接管 ServiceNow 執行個體及其後端連線環境。
現實應用
真正需要立刻處理的，是把 ServiceNow 當成 ITSM、客服、資產管理或企業流程中樞的組織，尤其金融、政府、大型企業與代管服務商。由於平臺通常握有工單、員工、系統設定及跨系統連線權限，攻擊成功後可能成為橫向移動跳板。資安團隊也應檢查對外暴露的執行個體、異常帳號建立、敏感資料表查詢，以及 MID Server 上不明指令活動。
期望評估
我認為低標期望是先確認版本並完成更新，至少能封住已公開的攻擊路徑；官方目前表示尚未發現實際利用，但這不等於可以延後處理。高標來看，我認為這次事件可順便盤點 ServiceNow 與 MID Server 的權限邊界、網路分段和監控紀錄，把原本過大的整合權限一起收斂。
商業策略分析
我猜受影響最大的除了 ServiceNow 客戶，還包括導入顧問、MSSP 與第三方整合商，因為客戶接下來會追問修補狀態、暴露範圍與稽核證據。對 ServiceNow 而言，雲端環境在通報後一天內先部署緊急緩解，反應算快；但事件也提醒市場，企業 AI 平臺若同時能查資料、建立帳號及呼叫代理伺服器，沙箱失守的商業風險會遠高於一般聊天工具。值得跟進的不是「AI 有漏洞」這個標題，而是高權限自動化平臺是否具備真正的最小權限設計。
實作細節
ServiceNow 已替託管執行個體部署安全更新；自行架設的客戶與合作夥伴則應依官方公告套用對應修補或升級至已修正版。NVD列出的修補基準涉及 Australia Patch 2、Yokohama Patch 12 Hot Fix 1b／Patch 13、Zurich Patch 7b／Patch 9，以及 Brazil EA／GA；實際適用版本仍應以客戶入口顯示的更新為準。