事件背景：三個滿分，不只是三張修補單
已證實事實：ServiceNow 於 2026 年 8 月下旬修補 AI Platform 的三項重大漏洞：CVE-2026-18885、CVE-2026-18886 與 CVE-2026-74820。三者的 CVSS 4.0 基礎分數均為最高的 10.0，攻擊條件包含可透過網路觸及、複雜度低、不需既有權限，也不需使用者互動。另有一項高風險沙箱逃逸漏洞 CVE-2026-6876，可讓具基本權限者達成遠端程式碼執行。原始報導見 https://www.csoonline.com/article/4215430/servicenow-patches-three-maximum-severity-flaws-that-could-put-enterprise-data-at-risk.html。
ServiceNow 表示，代管於其雲端的實例已部署安全更新，也已向合作夥伴及自行架設的客戶提供修補；公告當時尚未發現針對這批漏洞的惡意利用。加拿大網路安全中心的獨立通報則確認，受影響範圍橫跨 Xanadu、Yokohama、Zurich 與 Australia 等版本線，並要求管理者檢查官方公告及套用必要更新：https://www.cyber.gc.ca/en/alerts-advisories/servicenow-security-advisory-av26-857。ServiceNow 官方公告入口為 https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB3152242。
三個缺口如何改變平台的信任邊界
CVE-2026-18885 是 GraphQL Composite Data API 的程式碼注入漏洞，特製輸入可能被系統當成指令執行，讓未登入攻擊者執行任意程式碼，並存取或修改實例資料。CVE-2026-18886 涉及系統設定影像上傳處理器的存取控制不當，可讓未驗證使用者建立或更動資料，進而提升權限。CVE-2026-74820 則是 SQL 注入，攻擊者可能向底層資料庫送入非預期查詢，改動實例資料。獨立資安媒體亦核對了漏洞條件與各版修補門檻：https://www.bleepingcomputer.com/news/security/servicenow-warns-of-three-max-severity-security-vulnerabilities/。
合理推論：這三個缺口若被串連，風險不會停在「偷看一張工單」。程式碼執行可取得應用程式層面的立足點，資料寫入與提權可改變角色、紀錄或流程狀態，SQL 注入則直接威脅資料完整性。由於 ServiceNow 常被放在 IT 服務、資產、員工服務、資安事件及核准流程的交會處，攻擊者更可能把它當成前往其他系統的轉運站，尋找 API 權杖、服務帳號與整合連線。
為何現在值得注意：AI 是放大器，不一定是根因
這起事件最值得警惕之處，不是「AI 又出包」，而是掛上 AI 與自主代理功能的企業平台，底層仍可能敗在已有數十年歷史的輸入驗證、存取控制與 SQL 注入問題。現有公開資料能證明漏洞存在於 ServiceNow AI Platform，卻不足以證明生成式 AI 本身造成這三個弱點；把兩者直接畫上因果等號，反而會模糊真正需要修正的安全工程問題。
作者觀點：AI 真正改變的是攻防速度與爆炸半徑。對攻擊者而言，自動化工具可協助解析公告、調整輸入與大量探測公開介面；對企業而言，AI 平台又往往被授予更多資料來源、流程操作權與跨系統連接能力。因此，即使弱點仍是傳統注入攻擊，一旦落在高度整合的平台，後果可能比一般單點應用更廣。
實際影響：雲端已更新，不代表客戶工作結束
代管客戶與自行架設客戶面臨的第一個差異，是誰負責把修補真正部署上線。官方已更新雲端實例；自架、由合作夥伴代管，或維持特殊版本分支的組織，則必須自行核對版本與 Hot Fix。即使是雲端客戶，也仍需檢查修補前是否出現異常活動，以及整合憑證是否可能受到波及。供應商負責平台程式修補，客戶仍掌握帳號權限、資料分類、介面暴露與稽核紀錄，這正是 SaaS 共用責任容易被忽略的一段。
- 盤點所有正式、測試、災難復原及合作夥伴管理的 ServiceNow 實例，逐一比對官方修補版本。
- 列出對外 API、GraphQL 端點、上傳功能，以及具有管理權限的服務帳號與整合權杖。
- 回溯檢查異常 API 請求、非預期的角色變更、紀錄建立或修改、敏感資料大量讀取，以及服務帳號在下游系統的異常行為。
- 若發現可疑跡象，調查範圍應延伸至身分系統、工單串接、資產管理、安全工具及其他下游服務，不能只重建 ServiceNow 本身。
容易忽略的限制
首先，「尚未發現惡意利用」不是「證明從未遭利用」。它只代表供應商在公告時沒有掌握相關證據，不能取代客戶自己的日誌調查。其次，CVSS 10.0 描述的是技術上的最壞條件，不等於每個實例都有相同暴露程度；是否可從網際網路到達、相關功能是否啟用、資料與整合權限多大，都會改變實際風險。
此外，公開資訊尚未提供完整攻擊程式、已確認受害者數量或台灣受影響機構名單，因此不能宣稱台灣已發生入侵，也不宜憑空估算損失。現階段合理的優先級依據，應是版本、可達性、權限與資料敏感度，而不是新聞聲量。
對台灣組織的意義與後續指標
對採用 ServiceNow 的台灣金融、製造、科技與大型服務業而言，平台內可能集中跨國員工、IT 資產、供應商、弱點處理及資安事件流程。企業應把這次事件視為一次「核心流程平台」演練：資安團隊是否知道所有實例由誰維運？能否在一天內確認版本？是否看得到 API 與服務帳號的歷史行為？發現平台遭竄改後，又能否判斷哪些下游系統需要撤銷權杖或重設信任？
接下來應持續觀察五項訊號：ServiceNow 是否更新利用狀態或受影響版本、CISA 已知遭利用漏洞清單是否納入相關 CVE、是否出現可信的公開概念驗證程式、偵測規則與入侵指標是否發布，以及企業內修補與日誌回溯是否真正完成。這批漏洞的核心教訓並不新潮：平台愈智慧、整合愈深，輸入驗證、最小權限、介面縮減與可追溯性反而愈不能被視為舊時代的基本功。