Google AI代理 PageBreak 在自家Web應用程式找出逾500個XSS漏洞

Google 公布了 PageBreak 的細節，這是一套在公司自家Web應用程式中尋找資安漏洞的內部AI代理。Google 資安工程師米哈烏．本特科夫斯基（Michał Bentkowski）在公司部落格寫道，經過大規模執行，它已在 Google 第一方Web應用程式中找出超過500個跨站指令碼（XSS）漏洞，部分出現在敏感網域；iThome 也報導了相同數字。

跨站指令碼是一類漏洞：攻擊者設法把 JavaScript 程式碼注入其他使用者瀏覽的網頁，進而可能以受害者的工作階段身分行事。這是Web應用程式最常見的漏洞之一。

PageBreak 想解決的問題：AI雜訊

Google 解釋，以大型語言模型掃描程式碼改變了漏洞管理，卻也帶來雜訊。許多資安團隊不堪負荷，因為收到的疑似漏洞報告中，有相當比例是未經驗證的假設，或是模型充當靜態程式碼分析工具時產生的誤判，Google 稱之為「AI垃圾」（AI slop）。要分辨真正可利用的漏洞與看似可信的幻覺，已成為重大挑戰，常常反而增加產品團隊的負擔。

據 Google 說明，PageBreak 於2025年11月以試行計畫起步，2026年1月成為正式專案。它可搭配不同模型運作，但多數使用基於 Gemini 模型，例如 Gemini 3.1 Pro 與 Gemini 3.5 Flash。

驗證工具如何運作

關鍵的設計選擇是確定性驗證。代理找出潛在漏洞後，會把假設交給一個非AI撰寫的專用驗證工具，針對正在執行的環境實際執行酬載，確認漏洞能否被利用。未經驗證的疑似漏洞絕不會送交產品團隊。Google 表示，這讓誤判率接近零，iThome 也強調這一點。

• XSS：注入 JavaScript 酬載，在渲染環境載入URL，檢查注入的程式碼是否真的執行。
• SQL注入：從輸出或回應時間判斷資料庫查詢能否被操弄。
• 路徑穿越：在所有人可讀的位置建立檔案，檢查應用程式能否讀取。
• 遠端程式碼執行（RCE）：嘗試加入延遲、寫入檔案或觸發對外DNS／HTTP請求等方法。
• 伺服器端請求偽造（SSRF）：偵測應用程式是否向內部服務發出請求。

Google 坦言，驗證工具目前還無法涵蓋所有漏洞類型或複雜情境，因此有漏報風險。未經驗證的發現會保留在內部：作為後續掃描深入檢查的起點，指出需要開發新驗證工具之處，代理也會回報自己缺少哪些能力或存取權限而無法確認某項發現。

人工先前沒發現的漏洞

據 iThome 報導，Google 也公布了 PageBreak 找出的3個高嚴重性漏洞案例，這些應用程式過去都曾由 Google 資安工程師及外部漏洞研究人員檢查，但當時並未發現相關漏洞。其中，PageBreak 在 admin.google.com 發現一項XSS，但攻擊者若要成功利用，請求必須帶有有效簽章。PageBreak 接著找到另一個端點，可讓該應用程式替帶有惡意內容的參數產生有效簽章，進而建立繞過簽章保護的漏洞利用URL。Google 認為，這類案例顯示大型語言模型已逐漸能找出需要經過多個步驟才能利用的漏洞。

Google 在 Bug Hunters 部落格發布了配套文章，說明這些漏洞利用的技術細節。據 Google 表示，其中包括一個因服務設定錯誤造成的複雜快取汙染漏洞，以及一個代理完全自行繞過加密保護的案例。這些例子之所以重要，是因為它們超出了傳統掃描器已能偵測的簡單注入模式。

Google 表示，代理也受益於 Google 特有的優勢：一個擁有數十億行程式碼的單一程式庫；能把實際HTTP流量對應到原始碼行數的資安訊號；以及一套幾乎能登入所有 Google Web應用程式的既有掃描器。為提高成功機率，Google 會以相同種子讓代理跑多輪迭代。

「安全始於設計」框架帶來的差異

最引人注目的結果與建構在 Google 高保證Web框架上的應用程式有關，這些框架的設計目標是預設排除可被利用的Web漏洞。Google 寫道，截至2026年9月4日，PageBreak 在數百個以這些框架打造的應用程式中僅找到2個XSS漏洞，且都限於內部應用程式或強化不足的除錯端點。即使經過驗證，報告數量仍前所未見，因此 PageBreak 正與 CodeMender 等會產生自動修補的其他代理合作，目標是讓產品團隊最終只需確認提出的修補。

對台灣企業意味著什麼

對開始收到AI產生之漏洞報告的台灣軟體業者與企業內部資安團隊而言，Google 的做法提供一條實用原則：在確定性測試重現漏洞利用之前，不要只憑模型的懷疑採取行動。框架方面的結果同樣實用：抵禦自動化攻擊者最省成本的方法，是把Web應用程式建構在能預設阻擋整類漏洞的框架上，而不是事後逐一追查錯誤。