PHP 漏洞為何引發全球警戒？了解 AI 如何改變資安攻防戰

2026 年 10 月 21 日，日本首相高市早苗在 X 發文，提醒網站管理者準備更新 PHP。一次 PHP 安全更新，為什麼需要由首相出面呼籲？同一時間，荷蘭國家資安中心 NCSC 與部分政府機關也預防性關閉網站，在完成修補前先暫停對外服務。

本篇 Aiworks 將解釋這次 PHP 漏洞的影響、為什麼兩年前就發現的問題遲遲未修好，再看 AI 是如何改變現今的資安攻防戰。

PHP 漏洞會造成哪些後果？

當你打開一篇 WordPress 文章，或在購物網站查詢訂單時，你看見的網頁可能就是伺服器執行 PHP 程式後產生的。

這次漏洞讓使用 PHP 的不同網站都有機會受到影響。攻擊者在特定條件下，能讀取資料庫連線密碼、API 金鑰等敏感資料。即使網站表面上仍正常運作，背後的資料也可能正在外洩。

依 Censys 在 2026 年 10 月 23 日更新的全球觀測，其掃描辨識出約 6,760 萬個使用 PHP 的網站服務。而根據 W3Techs 的統計，在能辨識伺服器端程式語言的網站中，約七成使用 PHP。這次漏洞出在廣泛共用的底層軟體，讓不同網站的營運者都需要留意更新。

對來不及完成修補的機構或是企業而言，預防性關閉網站成了不得已的選擇。

兩年前，PHP 開發者在一次修正工作中，就已經發現記憶體不足時發生的異常行為，也推測可能衍生安全風險。但當時還沒有人找出具體攻擊方法，其他影響明確的問題因而占據較高的處理優先順序。

事實上，安全團隊也曾著手修補。依 PHP Foundation 的事件回顧，團隊提出了幾種修補方式，卻遲遲無法在相容性、安全風險與第三方擴充的配合成本之間選定方案。

另外，熟悉引擎的開發者人力也有限，所以修補在數月間反覆啟動又停滯。

直到 2026 年 8 月，研究者通報了能讓攻擊者遠端執行程式碼的具體攻擊方法，才讓這個 PHP 問題的危害變得明確。修補這個問題因此成為基金會安全團隊的最高優先事項，並在 10 月 21 日發布修正版本。

Wiz 指出，將多個弱點串成可運作的攻擊，複雜程度接近人類研究者實務上能處理的極限，而 AI 能協助完成這些步驟。

同時，AI 也降低了把攻擊調整到不同環境的成本。版本、設定與應用程式不同，原本成功的路徑就可能失效；但透過 AI，這些差異分析、重新測試，都變得更加容易且快速，導致攻擊更容易擴展到其他情境。

以 PHP 為例，參與防護的包括安全團隊與核心開發者、資助維護工作的 PHP Foundation，以及協助研究、提供主機服務與防護措施的外部公司。這些角色需要共同投入，才能將漏洞發現、程式修補與使用者端的更新銜接起來。

除此之外，面對新漏洞，這些團隊也會先私下協作，準備修補方案、更新套件與指引，再約定對外公布的時間。這種安排稱為「協調公布」：讓相關供應商能提前做好防護，也讓公眾得知漏洞時，同步取得防護資訊。

AI 輔助找漏洞，已經有多種專門工具。OpenAI 的 Codex Security 提供程式碼安全分析與問題驗證；Anthropic 的 Claude Security 協助掃描與驗證發現；Google 的 CodeMender 也將尋找、驗證與修補漏洞納入工具功能。

漏洞發現後，接著是一連串耗時的流程：設計可靠的修補方式、測試正常功能，再由網站營運者盤點受影響的系統、安排更新時程。

Verizon 2026 DBIR彙整了超過 1.3 萬個組織的資料。相較前一份報告，組織面對的 KEV 漏洞數中位數從 11 個增加到 16 個；完整修補時間指標的中位數從 32 天延長至 43 天；完整修補比例則從 38% 降至 26%。這組年度比較顯示，企業原本沉重的修補負擔正進一步加重。

面對 AI 帶來的資安風險，我們可以保持警覺，不必過度恐慌。發現漏洞與完成穩定攻擊之間，仍需要專業判斷與反覆測試。以 Calif 的 PHP 研究為例，研究者憑藉對系統與過往漏洞的理解，才能逐步找出可行的攻擊方法。

另外，防守方的研究機構、AI 公司與維護團隊，也在同一時間利用同樣的能力尋找問題與修補漏洞。不過，前述 DBIR 數據顯示，企業原本的修補負擔已經在加重。

AI 能更快找出漏洞，企業也需要確保足夠的人力與資源，完成後續的修補與驗證。當這些後續工作能跟上，才有機會讓組織變得更加安全。

Aiworks 提供企業內訓、客製化培訓與實作工作坊，協助各產業團隊規劃生成式 AI 的導入與應用策略。

▼ 聯絡我們｜規劃你的 AI 實戰課程，讓轉型真正落地 ▼

（若表單未正常顯示，請點擊此連結進入表單填寫頁面）