Etairos.ai

TL;DR

  • what: 威脅行為者正積極利用 CVE-2026-6875，這是一個嚴重（CVSS 9.5）的 ServiceNow AI Platform 沙箱逃逸漏洞，允許未經身份驗證的攻擊者透過預先身份驗證端點執行任意程式碼。
  • impact: 成功利用將導致 ServiceNow 執行個體及所有連接的代理伺服器遭到完全入侵，暴露 ITSM 資料、憑證以及跨環境的整合。
  • fix: 立即套用 2026 年 6 月的 ServiceNow 修補程式：Brazil EA/GA、Australia Patch 2、Zurich Patch 7b 或 9，或 Yokohama Patch 12 Hot Fix 1b 或 Patch 13。
  • who: 任何在未修補版本上執行自託管 ServiceNow 執行個體的組織，都暴露於未經身份驗證且具公開 PoC 的攻擊風險；ServiceNow 託管客戶應確認其修補狀態。

攻擊者正在利用 ServiceNow AI Platform 中的一項關鍵沙箱逃逸漏洞，取得執行個體的未經身份驗證程式碼執行權限。CVE-2026-6875 的 CVSS 評分為 9.5，無需憑證即可利用。根據揭露公司 Searchlight Cyber 的說法，這將導致 ServiceNow 執行個體及其連接的每個代理伺服器遭到完全入侵。威脅情資公司 Defused Cyber 於 2026 年 7 月 21 日報告了野外利用事件，擷取的酬載與 Searchlight 的公開概念證明相符。修補程式自 6 月起已提供。若您執行自託管執行個體且尚未套用修補，請將此視為今日的防範事件，而非排程變更項目。

漏洞是什麼

CVE-2026-6875 是 ServiceNow AI Platform 中的沙箱逃逸漏洞。ServiceNow 與大多數低程式碼及 AI 啟用平台一樣，會在受限沙箱中執行使用者及工作流程提供的程式碼，以防止該程式碼存取底層主機或執行個體內部。此漏洞突破了此邊界。一旦沙箱限制消失，攻擊者的輸入就不再是受沙箱限制的指令碼，而是以平台自身權限執行的任意程式碼。

此漏洞的關鍵放大因素是該利用可在身份驗證前存取。Defused Cyber 觀察到針對端點 '/assessment_thanks.do' 使用 HTTP POST 請求的利用行為。該端點無需有效工作階段即可存取，這意味著攻擊者不需要竊取的憑證、網路釣魚立足點或內部人士。網際網路面向暴露加上未修補版本即為全部先決條件。

⚠️ Pre-auth RCE 表示無登入步驟可供偵測 — 由於 CVE-2026-6875 可在身份驗證前被利用，因此沒有失敗登入模式、憑證填充高峰或 MFA 提示可供警示。第一個可觀察到的訊號可能是程式碼執行本身。請在 POST 請求至 /assessment_thanks.do 以及 ServiceNow 應用程式層中意外的子程序或對外連線上進行搜尋。

為什麼影響範圍很大

ServiceNow 執行個體很少是孤立的。它通常儲存 IT 服務管理資料、資產及設定記錄、工作流程自動化，以及其整合系統的儲存憑證。Searchlight Cyber 的揭露指出，此漏洞允許完全入侵執行個體以及所有連接的代理伺服器。這將單一易受攻擊的平台轉變為進入其餘環境的樞紐點。

  • 完整執行個體入侵：對 ITSM 工單、CMDB 記錄及執行個體中儲存的任何機密具有讀取/寫入存取權限。
  • 連接的代理伺服器：橫向進入這些代理橋接的網路區段。
  • 整合憑證：ServiceNow 通常儲存下游系統的 API 金鑰及服務帳戶，將攻擊者的觸及範圍延伸至平台本身之外。
  • 自動化濫用：工作流程及編排功能可被重新利用，以受信任的身分在整個環境中執行動作。

時間軸與揭露

Searchlight Cyber 於 2026 年 4 月 1 日向 ServiceNow 報告此問題。ServiceNow 在 6 月期間在其支援的版本系列中推出修復程式。Defused Cyber 在 7 月 21 日標記了野外利用，大約在初始報告後 111 天，且在修補程式可用後數週內。從廠商修復到野外利用的這種壓縮時間，是具有公開 PoC 的高嚴重性企業漏洞的 recurring 模式：有助於防禦者修補的揭露，也武裝了反向工程修復的攻擊者。

Defused 的報告包含一項值得注意的更正。該公司最初暗示觀察到的酬載透過不同於已發布 PoC 的途徑達到相同的程式碼執行原語，隨後自行更正確認擷取的酬載與 Searchlight Cyber 的 PoC 相符。實際上，攻擊者正在使用公開利用程式，而非自訂變體。

廠商立場

在發布後，ServiceNow 發言人告訴 The Hacker News，該公司迄今未觀察到利用證據，特別是未見任何與 ServiceNow 本身託管的執行個體相關的活動。ServiceNow 重申修補程式已提供，並敦促自託管及 ServiceNow 託管客戶套用修補程式，為需要協助的客戶提供直接協助。請注意聲明的範圍：它針對 ServiceNow 託管的基礎架構。自託管執行個體不在廠商的遙測範圍內，而 Defused 的利用報告並不限於託管環境。廠商自身機隊缺乏證據，並不代表每個自行管理的部署都沒有證據。

修補矩陣 — 套用您版本系列的修復版本：Brazil EA 和 Brazil GA；Australia Patch 2；Zurich Patch 7b 或 Zurich Patch 9；Yokohama Patch 12 Hot Fix 1b 或 Yokohama Patch 13。根據研究人員 Adam Kues 的說法，ServiceNow 也正在透過嚴格限制允許在沙箱情境中執行的程式碼類型來強化平台。

現在該怎麼做

  • 立即修補：將任何自託管執行個體移至修復版本（Brazil EA/GA、Australia Patch 2、Zurich Patch 7b/9，或 Yokohama Patch 12 Hot Fix 1b/Patch 13）。這是主要緩解措施。
  • 回溯搜尋：檢閱網路及應用程式日誌中 HTTP POST 請求至 /assessment_thanks.do 的記錄，並檢查 ServiceNow 應用程式層中意外的程序、對外連線或新帳戶。
  • 假設沙箱未保留任何東西：若您發現利用證據，請將連接的代理伺服器及執行個體中儲存的任何憑證視為已入侵並輪換它們。
  • 降低暴露：若業務需求允許，請限制平台的網際網路面向存取，並在受影響的預先身份驗證端點前放置 WAF 規則作為權宜之計，而非取代修補。
  • 確認託管狀態：即使您是 ServiceNow 託管，也請驗證您的執行個體位於修補版本上，而非依賴廠商的機隊範圍聲明。

核心原則很簡單。這是一個 CVSS 9.5、未經身份驗證、具公開 PoC 的遠端程式碼執行漏洞，存在於通常位於 IT 營運中心的平台中，並持有存取所有其他系統的憑證。修補程式存在。擁有修復與套用修復之間的差距就是這裡的整個攻擊面，而攻擊者已經處於這個差距中。

Originally published on RedEye Threat Intelligence.