週五弱點會議一打開，high / critical 報告突然多出幾百筆，產品資安、SRE、平台工程和開源維護者要在同一個下午判斷：哪些真的可利用、哪些只是重複報告、哪些缺少證據、哪些修補會牽動多個服務。這種塞車會讓真正急件等不到工程時間，也會讓低品質 AI 報告反覆消耗維護者。
Epoch AI 的 CVE data explorer 在 2026-07-03 更新後，The Decoder 根據該資料整理出一個值得警惕的數字：2026 年 6 月，21 個組織回報約 1,500 筆 high-severity 與 critical CVE，超過先前月紀錄 3.5 倍。這個跳升和 Anthropic Claude Mythos Preview、Project Glasswing、OpenAI Daybreak 等 AI 找漏洞計畫的時間點相近；安全讀法是「AI 正在把漏洞發現速度往前推」，但單月 CVE 數字還不能證明每一筆都由 AI 產生。
本週先別恐慌，也別把所有 AI 漏洞報告丟進同一個待辦清單。把報告分成三條隊列：可遠端利用且證據完整的先重現，影響範圍大但證據不足的先退回補件，低影響或重複報告延後處理。這樣才不會讓 AI 找漏洞的速度，變成工程和維護團隊的塞車成本。
新數字補上的變化：發現變快，消化能力沒跟上
Project Glasswing 原本已經把問題講得很清楚。Anthropic 在 2026 年 5 月更新中說，Claude Mythos Preview 與約 50 個合作夥伴找到超過 1 萬個 high/critical 漏洞；在開源掃描部分，Mythos Preview 估計找到 6,202 個 high/critical 候選，其中 1,752 個已被獨立資安研究單位或 Anthropic 評估，90.6%（1,587 個）被確認為 true positive。
7 月的 Epoch AI / The Decoder 數字把這件事從單一計畫拉到整個 CVE 回報量。它不直接證明所有新增 CVE 都來自 AI，但會改變資安團隊的假設：未來幾個月，更多工具、研究員和廠商會用 AI 擴大掃描，弱點管理不能再把「每月新增量大致穩定」當成預設。
| 看到的變化 | 不該過度解讀成 | 本週該補的動作 |
|---|---|---|
| June 2026 high/critical CVE 回報量跳升 | 每筆都是 AI 找到，或每筆都已可被利用 | 把 CVE 來源、證據、受影響資產和重複關係放進同一張分流表 |
| Glasswing 找出大量 high/critical 候選 | 模型輸出可以直接進入公告或修補 | 要求重現步驟、受影響版本、最小 proof-of-concept 和人工確認 |
| true positive 率比傳統 AI 掃描印象高 | 誤報問題已經消失 | 保留退回補件規則，避免維護者被低證據報告拖垮 |
| AI 讓發現速度提高 | 安全會自動變好 | 把驗證、patch、部署和客戶通知排進同一個節奏 |
如果團隊正在看 AI 掃描工具，可以把這篇和 Cloudflare 漏洞調度框架 一起讀：採購問題要落在每一筆報告能不能被保存、重跑、反駁、去重，最後接到修補；展示裡丟出多少報告只適合作為參考。
一個實務場景：弱點會議被 AI 報告塞滿
想像一個 B2B SaaS 團隊。資安窗口週五收到 180 筆新的 high / critical 報告，其中 60 筆來自自家掃描器，40 筆來自供應商公告，80 筆來自外部研究員或 AI 輔助通報。產品工程只有兩個人能在週末前協助重現，SRE 還要判斷哪些服務曝露在外網，法務和客戶成功團隊則等著知道要不要通知客戶。
如果所有報告只用 CVSS 或「high / critical」排序，團隊很快會卡住。第一批工程時間應該留給同時具備四個條件的報告：證據能重現、資產在外網或處理敏感資料、可被遠端利用、修補或緩解可以在短時間內部署。
只有模型描述、沒有受影響版本、沒有最小重現步驟的報告，就算標成 critical，也應該先退回補件。維護者可以把有限時間留給可驗證、可修補、會影響使用者的項目，同時要求回報者補齊證據。
本週先改成三條處理隊列
第一條是「先重現」。條件是外網曝露、可能遠端利用、證據完整，或已經有公開 exploit / 攻擊跡象。這一隊要有明確負責人、重現環境、修補分支、測試與部署窗口；對 SaaS 服務，還要同步評估是否需要客戶通知。
第二條是「先補件」。條件是影響可能很大，但目前缺少版本範圍、proof-of-concept、可利用路徑或重複關係。這一隊不應該躺在 backlog 裡等人有空，而要在 24–72 小時內回覆回報者或掃描系統：需要哪些證據，什麼格式可接受，什麼情況會升級到第一條隊列。
第三條是「先延後」。條件是內網低影響、已被既有控制緩解、和已知 CVE 重複，或只描述理論風險。延後不等於丟掉；要保留來源、判斷理由和下次複查時間，避免同一個 AI 報告換個說法又重新消耗一次會議。
這套分流也適合拿去檢查現有 AI 資安產品。看到「自動找漏洞」的展示時，別只問找到幾個，要問：能不能去重？能不能附上重現？能不能對應資產清單？能不能把修補狀態回寫到 issue tracker？如果做不到，掃描變快只會讓待辦清單變厚。
對 Project Glasswing 的正確讀法
Project Glasswing 值得關注，因為它展示了 frontier model 在防守用途上的能力，也讓人看見負責任揭露制度的壓力。Anthropic 說有些維護者要求放慢揭露速度，因為設計 patch 需要時間；這句話比「找到 1 萬個漏洞」更接近日常成本。
對企業來說，Glasswing 的提醒很直接。第一，AI 可能讓競爭者、研究員和攻擊者都更容易找到同一類漏洞。第二，防守方要把「找得到」轉成「修得完」。第三，資安流程要能處理大量半成品報告，不然 AI 只會把噪音放大。
如果你正在建立代理或工具權限治理，可以接著看 AI-SPM 指南；如果焦點是讓模型協助原始碼安全審查，則可以延伸到 Claude Opus 掃原始碼安全漏洞流程。兩篇的共同點都是：模型能力只是一層，紀錄、審查、權限和修補節奏才會決定風險有沒有下降。
接下來看三個指標
第一個指標是重現時間。AI 報告進來後，團隊要知道從收到到確認 true positive 需要多久；如果重現時間比發現速度慢太多，報告量越大，越容易排擠真正急件。
第二個指標是修補吞吐量。每週能合併多少修補、跑完多少回歸測試、部署到多少受影響服務，比「本週又找到多少漏洞」更能反映安全是否變好。
第三個指標是退回補件率。AI 產生或轉述的報告如果缺少版本、重現步驟、影響範圍，應該被清楚退回，避免消耗會議時間。退回規則越清楚，外部研究員、內部掃描器和模型輸出越容易被整理成可處理的工作。
公開 benchmark 和模型能力報告仍有參考價值，但正式採購或上線前，最好回到自己的任務和資料做驗證。若團隊還沒有完整評測方式，可以先用 LLM 評估指南 建一組小型任務集，再把漏洞報告的品質、重現成本和修補時間一起記錄。
FAQ
June 2026 的 CVE 暴增代表 AI 已經造成資安災難嗎？
目前更安全的說法是：AI 輔助漏洞發現正在推高回報量，但單月 CVE 數字不能直接等於實際被攻擊數，也不能證明每一筆都由 AI 找出。資安團隊應該提高警覺，先補驗證、去重和修補流程，不要把統計圖解讀成單一成因。
企業應該立刻買 AI 漏洞掃描工具嗎？
先檢查現有流程能不能承接更多報告。若資產清單不完整、issue tracker 沒有弱點分流、修補部署很慢，再強的掃描工具也只會增加 backlog。比較好的起點是選一個低風險範圍試跑，要求每筆報告附上重現、版本、影響和修補建議，再看團隊能否在固定週期內處理。
開源維護者可以怎麼避免被 AI 報告淹沒？
先公布回報格式：受影響版本、最小重現步驟、預期影響、是否已檢查重複 issue、是否包含自動產生內容。缺少這些資訊的報告可以先退回補件。這樣做是在保護維護者時間，讓可驗證的漏洞更快被修。