AI加快漏洞發現之後，真正的考驗是把修補送到運行中的系統

漏洞情報公司VulnCheck稱CVE數量年增100%，並將AI發現工具與編號機構能力擴張共同列為可能因素；其公開文字未清楚界定這項比較的資料期間。¹這個數字值得關注，卻不能直接改寫成「所有軟體漏洞翻倍」，更不能據此認定AI是唯一原因。

AI生成示意圖：伺服器、斷開的網路線與檢修工具表現網路安全事件調查和修復，非真實企業事故現場。

揭露數量、可利用性和實際入侵，是三個不同問題。發現更多問題，既可能揭示原來存在卻沒有被記錄的風險，也可能反映通報與登記能力增強。對使用軟體的企業而言，更迫切的問題不是誰發現了最多漏洞，而是哪些缺陷影響自己的系統，以及修補何時真正生效。

PHP更新提示：嚴重程度與攻擊機率要分開

PHP在10月21日發布8.5.12、8.4.27、8.3.36和8.2.35，修補兩項嚴重遠端程式碼執行漏洞；23日另有工作階段上傳進度公告，涉及不常見的設定組合。²不應把不同前提下的問題合併成一種無差別風險，也不應把後一份公告理解為前一輪安全更新沒有價值。

荷蘭國家網路安全中心NCSC-NL在23日更新中稱利用複雜、大規模利用可能性低於先前判斷，但仍要求儘快修補；其網站下線屬於預防措施。³因此，服務暫停不能直接作為成功入侵的證據；風險評估緩和，也不等於可以擱置修補。

這種區分對決策很重要。嚴重程度描述一旦成功可能造成的後果；實際風險還取決於系統是否暴露、是否符合受影響條件、能否被利用，以及承載什麼業務。將所有伺服器一律視為已經失陷會製造無謂中斷，把「目前較難利用」視為永久保護則會延長暴露期。

PHP基金會稱，記憶體不足問題的早期線索來自2024年稽核後續工作；不能把所有發現階段都歸功於AI。⁴

更多通報為何未必立刻帶來更安全的軟體

從軟體使用方看，一次更新請求還要對應具體資產、業務負責人和可執行的部署計畫。缺少這些資訊，再快收到公告也未必縮短暴露期。NIST強調技術團隊與業務負責人在修補策略上的協調，將維護視為正常營運的一部分。⁵發現速度與回應能力之間的落差，應據此觀察，而不能只用通報數量推算某個專案的積壓規模。

NIST的修補規劃區分日常修補、緊急修補、緊急緩解和無法修補資產等情境。⁵由此看，組織不應在每次緊急公告後才臨時爭論誰可以批准停機。應在平時確定業務負責人、維護時段和向上通報路徑，事件發生時再按實際影響選擇方案。重點是減少內部協調耗時，而不是假設任何修補程式都可以不經測試立即使用。

同樣，AI工具提出一個可疑結果，也不應該自動取得對正式環境執行驗證的權限。受控測試、最小必要存取和人工審查仍有價值。防守方追求的是可靠消除風險，而不是以更多自動化活動取代對結果的確認。

修補是一條到達正式環境的鏈路

NIST在SP 800-40 Rev. 4中把修補程式管理視為技術的預防性維護，涵蓋識別、排序、取得、安裝與驗證，並強調持續維護軟體和資產清單。⁵這套架構有助於解釋，為什麼公告發布和企業完成修補之間不能畫等號。

第一步是確認軟體究竟運行在哪裡。自建伺服器、代管服務、容器映像檔和嵌入第三方產品的元件，可能由不同團隊維護。資產清單若只有產品名稱，沒有版本、負責人和部署位置，安全團隊即使拿到準確公告，也難以判斷通知應該交給誰。

第二步是把優先順序與具體暴露連結起來。網際網路可達、權限較高或承擔關鍵業務的系統，需要更快完成評估；測試與回復安排則應根據業務容錯能力確定。臨時限制存取可以降低部分暴露，但不應因此把未修補事項從清單中永久刪除。

第三步是驗證正在提供服務的系統，而不只是檢查下載記錄。安裝套件已更新、建置流程已通過，都不自動證明每個運行中的執行個體已經採用新版本。NIST明確區分部署與驗證，並要求後續監測。⁵組織應保留部署結果、例外執行個體及複核責任，避免舊映像檔或遺漏節點再次把風險帶回正式環境。

對外包維運或代管服務，責任鏈尤其不能停在一句「供應商正在處理」。服務使用方需要知道由誰確認受影響範圍、誰執行變更、誰提供完成證明，以及未能按時處理時如何向上通報。詢問這些具體問題，比轉發一串漏洞編號更能推動風險得到解決。

修補缺陷不等於完成事件應變

如果已經出現可信入侵跡象，修補解決的是相關缺陷，不能單獨證明此前沒有發生未授權存取。此時還需要沿既有應變流程核實影響、保留證據並決定恢復措施。反過來，沒有入侵證據時，也不應把一項風險公告寫成已發生的資料外洩。

衡量防守能力，更有用的指標包括受影響資產識別涵蓋率、關鍵系統修補所需時間、部署驗證成功率，以及未解決例外是否有明確負責人。這些指標追蹤的是消除風險的過程，而不是把收到的通報或關閉的工單數量當作安全本身。

AI可以改變發現問題的速度，但組織是否更安全，仍取決於後續鏈路能否跟上。此次PHP更新及評估調整所揭示的，不是「越恐慌越謹慎」，而是判斷要隨著證據更新，修補責任卻不能隨著新聞熱度消失。

來源與說明

1. Patrick Garrity / VulnCheck，2026-10-22。Exploring the Risks and Impacts of AI on Vulnerability Discovery and Exploitation（探討AI對漏洞發現與利用的風險和影響）。 ↩

2. PHP，2026-10-21、2026-10-23。Security advisory: Critical remote code execution vulnerabilities, update now；Informational advisory: Session upload progress（安全公告：嚴重遠端程式碼執行漏洞，請立即更新；資訊公告：工作階段上傳進度），收錄於2026年新聞檔案。 ↩

3. NCSC-NL，2026-10-21發布，2026-10-23 15:45更新，頁面未註明時區。Update: PHP vulnerabilities remain a reason for immediate patching（更新：PHP漏洞仍需立即修補）。 ↩

4. The PHP Foundation，2026-10-21。Today's PHP Security Release, and How We're Strengthening PHP Security（今日PHP安全版本，以及我們如何加強PHP安全）。 ↩

5. Murugiah Souppaya / Karen Scarfone / NIST，2022-04-06。Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology（企業修補程式管理規劃指南：技術的預防性維護），SP 800-40 Rev. 4。Republished courtesy of the National Institute of Standards and Technology. 授權說明。 ↩ ↩² ↩³ ↩⁴