微軟六月一次修掉約 200 個漏洞、當中還夾著好幾個零時差，這則新聞真正該讀的重點不是「200」這個破紀錄的數字，是它為什麼會破紀錄：找漏洞的成本正被 AI 拉著往下崩，漏洞揭露的速度結構性上升，而且看起來回不去了。這件事對企業的意義很直接。你沿用多年的「每月一批、人工逐條評估、再排期上線」修補節奏，是建立在一個正在失效的前提上，也就是漏洞會以人讀得完的速率穩定滴出來。排程該改的不是「修快一點」，是改看什麼、怎麼分流。
先把事件講清楚。6 月 9 日微軟推出六月的 Patch Tuesday，修補數量各家算出來不一樣。資安媒體 Malwarebytes 說是 206 個、是這套機制自 2003 年上線以來最大的一次；Cyber Security News 數的是 198 個；資安研究機構 Zero Day Initiative 連第三方元件一起算，得到 208 個 CVE，並指出前一個單月紀錄是 177。差別在算不算進 Chromium 這類第三方漏洞。不管用哪個口徑，這個月都比過去任何一個月都多。
而更能說明狀況的，是連零時差的數字都對不起來。Malwarebytes 說是 3 個、而且沒有任何一個已知遭到實際攻擊；BleepingComputer 卻數出 6 個、其中一個正在被利用。連「哪一個正在被打」都各指不同：BleepingComputer 指向一個 Exchange 的欺騙漏洞，資安公司 CrowdStrike 點名的卻是 HTTP.sys 一個 CVSS 9.8 分的遠端執行漏洞（CVE-2026-47291）。這些不是小媒體亂寫，是這行最會追這件事的幾家，面對同一批修補、同一天，算出不一樣的帳。
數字為什麼會這樣暴衝，又為什麼連追蹤的人都跟不上？Zero Day Initiative 的分析師自己在報告裡把問題問了出來：這麼大的量，是不是有 AI 工具在幫忙找漏洞、甚至幫忙生修補。這不是空猜。資安情資公司 VulnCheck 追各家供應商今年的 CVE 增幅，Chrome 年增 563%、多家開源專案翻倍成長，而發掘漏洞的研究員自己形容工作流程已經是「八成靠 Claude、兩成由人收尾」。
把這件事拆開就懂了。傳統找漏洞的瓶頸是「有多少個夠強的研究員、每人一週能挖出幾個」。AI 把研究員換成可以平行跑、按算力計費的軟體，每個漏洞的發掘時間從幾週壓到幾小時。供給端的閘門一被打開，揭露量就是結構性往上，不是這個月剛好比較衰。
所以企業第一個反應通常是「那就每個月更用力修、把速度拉快」。這個方向沒有錯，但如果只做到這一步，很容易解錯題。你修得夠不夠快不是根因。根因是那套「每月一批、批量評估、逐條讀 CVSS 分數排優先級、再排期上線」的流程，它的隱含前提是漏洞以人讀得完的速率出現。當一個月冒出兩百條、而且連專業機構都分不清哪條真的在被打，先撐不住的會是人工逐條讀分數排序這個環節，不是修補的手速。
排程要改的，是三件具體的事。
| 環節 | 舊做法為什麼撐不住 | 改成 |
|---|---|---|
| 優先級 | 只看 CVSS 分數高低，一個月兩百條全排進去讀 | 先看「是否已被實際利用」，分數高不等於會被打 |
| 節奏 | 一個月一大批一起評估、一起上線 | 拆兩條線：已遭利用的插隊即時修，其餘按資產暴露面分流排期 |
| 分工 | 全靠人逐條讀完再決定 | 用威脅情資與自動化做前置篩選，但「哪條不修」的決策留在人這邊 |
CrowdStrike 在這次的分析裡也提醒，不是每個高可利用性的漏洞都好修，要先有一套回應計畫，而不是看到高分就硬上。第三點要特別踩個剎車：自動化可以幫你把該人看的挑出來，但別讓它替你決定某條「不修」。篩選是把範圍縮小，決策還是人的責任，誰簽字放掉哪一條、出事誰扛，這條界線不能交給工具。
台灣這邊的體感會更明顯。多數企業的 IT 和外包的資安服務商，本來就跟著微軟月更的節奏走，人力又長期吃緊，一個月兩百條、還要自己判斷哪條先修，靠人讀是真的讀不完。這裡的務實做法不是加人硬讀，是換一個優先訊號。與其守著 CVSS 分數高的那一大疊，不如先盯「已經在野外被利用」的那幾條，這類清單（例如美國 CISA 維護的 KEV 已知遭利用漏洞名錄）通常短很多，也才是真正會先燒到你的。這個原則跟前面那張表是同一件事：分數高不等於會被打，會被打的才要插隊。
把這件事收回來一句話：200 這個數字之後會一直被刷新，因為找漏洞的成本正在崩，這是回不去的方向，不是這個月的意外。企業要改的也不是修補的手速，是那套假設「漏洞會慢慢來」的排程。看懂數字為什麼在漲，比記住這個月是 200 還是 208 有用得多。剩下的判斷，哪條插隊、哪條先擱著、誰簽字放掉，這篇文章給不了你，那要你盤點完自己的資產暴露面才排得出來。工具能幫你讀，但排程是你的決定。
常見問題
微軟六月到底修了幾個漏洞、幾個是零時差？
約 200 個，各家從 198 到 208 不等，差別在算不算進 Chromium 這類第三方元件的漏洞。零時差的數字也對不起來，[Malwarebytes 說是 3 個](https://www.malwarebytes.com/blog/bugs/2026/06/microsofts-biggest-ever-patch-tuesday-fixes-206-bugs-including-3-zero-days)、[BleepingComputer 說是 6 個](https://www.bleepingcomputer.com/news/microsoft/microsoft-june-2026-patch-tuesday-fixes-3-zero-day-200-flaws/amp/)。不管用哪個口徑，這都是這套機制上線以來最大的一次。
這些漏洞有沒有正在被駭客利用？
有，但連追蹤機構都指向不同的 CVE：[CrowdStrike 點名 HTTP.sys 的 CVE-2026-47291](https://www.crowdstrike.com/en-us/blog/patch-tuesday-analysis-june-2026/)，BleepingComputer 指的是 Exchange 的欺騙漏洞，Malwarebytes 則說沒有任何一個已知遭利用。正因為連專家都對不起來，「先修已經在被打的那幾條」會比「先修分數最高的」更務實。
為什麼漏洞數量這個月突然爆這麼多？
主流研判是 AI 輔助發掘的結果。追蹤這件事的 [Zero Day Initiative 分析師直接把 AI 工具是否參與提出來問](https://www.zerodayinitiative.com/blog/2026/6/9/the-june-2026-security-update-review)，情資公司 [VulnCheck 的數據顯示今年多家供應商的 CVE 增幅翻倍、Chrome 年增 563%](https://www.vulncheck.com/blog/ai-assisted-vulnerability-discovery)。找漏洞的時間從幾週壓到幾小時，供給端的閘門被打開，量就回不去了。
我的公司該怎麼調整修補排程？
三件事。優先級別再只看 CVSS 分數，先看漏洞是否已列入「已遭實際利用」清單（如美國 CISA 的 KEV）；節奏上把「一個月一大批」拆成「已遭利用者插隊即時修、其餘按資產暴露面分流」；分工上用威脅情資與自動化做前置篩選，但「哪條不修」的決策留給人。這是流程問題，不是修補手速問題。
參考來源
- Microsoft's biggest-ever Patch Tuesday fixes 206 bugs, including 3 zero-days（Malwarebytes）
- The June 2026 Security Update Review（Zero Day Initiative）
- Microsoft June 2026 Patch Tuesday fixes 3 zero-day, 200 flaws（BleepingComputer）
- June 2026 Patch Tuesday: Updates and Analysis（CrowdStrike）
- The First CVE Wave: Signs That AI-Assisted Vulnerability Discovery Is Reshaping Disclosure Volumes（VulnCheck）
- Microsoft Patch Tuesday June 2026 – 198 Vulnerabilities Fixed, Including 3 Zero-days（Cyber Security News）
