PHP2Shell：AI 一週找出十年舊漏洞，多國政府網站預防性下線

10 月 21 日，全球網絡安全界經歷了一個罕見的下午：芬蘭政府資訊科技中心 Valtori 把多個公共網站下線，法國政府入門網站 info.gouv.fr 無法顯示，荷蘭與丹麥亦有政府站點暫停。原因不是黑客已攻入這些系統，而是源於一個剛公佈修補的 PHP 漏洞——這個漏洞讓攻擊者可在應用程式碼執行前，以普通 HTTP 請求取得伺服器控制權。不過 PHP 修補在 14:00（UTC）發布，攻擊卻早在 07:43 已出現，黑客已利用 AI 發動攻擊。

爆發時序重演：從發現到影響全球關站

兩個記憶體錯誤，為何等於一個 shell

用最簡單説法：PHP 在處理每一個網頁請求時，會先在記憶體裡建立一堆臨時數據，例如表單、上傳檔案、工作階段狀態。正常情況下，請求結束就會被清理。這兩個漏洞，正好破壞了「建立」與「清理」之間的秩序。

CVE-2026-109618 是記憶體不足時出錯。PHP 用 memory_limit 限制每個請求可用的記憶體，一旦超限就以 longjmp 中止請求；但中止發生的時候，某些內部數據只初始化了一半。之後的清理程序看到這些半成品，卻當成有效數據處理，於是產生記憶體腐蝕。CVE-2026-109619 則是「舊狀態未清」。同一個工作進程（worker）處理完一個請求後，部分狀態仍留在記憶體；下 一個請求在正常初始化之前，讀到了上一個請求的殘留，形成 use-after-free（釋放後使用）。

兩個錯誤都在 PHP 引擎內部，不在 WordPress、Laravel 或任何應用程式碼內，意味著即使你的網站程式碼乾淨、外掛全部更新，只要 PHP 版本受到影響，風險仍然存在。PHP 官方公告説得直接——所有處理網頁請求的 PHP 安裝都受影響，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 與 LiteSpeed；其中 mod_php 風險最高，因為攻擊可在應用程式碼執行前觸發（PHP 官方公告，2026 年 10 月 21 日）。

影響範圍由 PHP 5.4 起計，橫跨十多年版本；修補只覆蓋 8.2 至 8.5，較舊版本已不再由 PHP 專案提供更新，只能倚賴作業系統或商業支援廠商回溯修補。這就是所謂的長尾問題：已停止更新的 PHP 系統，不會因為官方發布修補而自動安全。不少開源軟件使用大量 PHP ，而用戶不知如何更新底層。

一個語言漏洞，震動半個互聯網

PHP 生於 1994 年，原本是 Rasmus Lerdorf 用來記錄個人履歷的小工具，後來演變成 PHP/FI、PHP 3（1998）、PHP 4（2000）、PHP 5（2004）、PHP 7（2015）與 PHP 8（2020）。PHP 所以流行，不是因為設計優雅，而是因為解決 2000 年代最實際的問題：以低廉的共享主機，把 HTML 與數據庫快速接起來。LAMP（Linux、Apache、MySQL、PHP）成為無數網站與公司的預設堆疊，其中的 WordPress 是全球最流行的內容管理系統(CMS），不少新聞網站都利用了 WordPress。

今日數字説明一切：W3Techs 的統計，PHP 用於 69.3% 已知伺服器端語言的網站；WordPress 佔去全球網站的 39.6%，佔已知 CMS 的 58.3%。Wiz 則稱 PHP 支撐全球七成網站（Wiz，2026 年 10 月）。WordPress、Joomla、Drupal、MediaWiki、Magento、Shopware、WooCommerce 全跑在 PHP 上；Laravel、Symfony、CodeIgniter 框架， PHP 也是生態主力。單頁應用（SPA）雖然前端用 React 或 Vue，後端 API 仍大量以 Laravel 或 Symfony 撰寫，所以網站是 SPA，不就等於伺服器沒有跑 PHP。

更麻煩的是看不見的 PHP。不少 PHP 藏在 NAS、印表機管理介面、舊的內聯網系統、財務軟件、監控設備、外包公司報表工具裡；上述系統沒資產清單，沒版本紀錄，甚至沒人記得存在。當安全團隊問企業內有沒有跑 PHP？答案往往是「應該沒有」，直到掃描器某個角落，才找到 5.6 版。

香港電商：WooCommerce、Drupal 與中小企的暴露面

香港不少中小型零售、餐飲、批發與跨境電商，以 WordPress 加 WooCommerce 建站；不少大型機構、大學與部分公營網站則常用 Drupal。兩者都是 PHP 應用，這次漏洞在引擎層，所以商戶即使把 WordPress 核心、主題與外掛全部更新，只要伺服器上的 PHP 未修補，風險仍然存在，但是不少共享架構，用戶不能自己更新。Sansec 的測試名單正好包括 WooCommerce 與 Drupal 11.4.3，明確指出 WooCommerce 商店即使商店自身的程式碼沒有問題仍然暴露（Sansec，2026 年 10 月 21 日）。

香港部署形態令問題更複雜。中小商戶多數把網站放在共享主機或託管環境，PHP 版本由主機商控制，商戶往往不知道實際的版本；促銷期又加裝大量外掛，活動結束後又沒人清理；付款多數經第三方 hosted payment page（例如 Stripe、PayMe、PayDollar），卡號不落在商戶伺服器，這是唯一的好消息；但若店鋪使用 direct POST 或在本機儲存卡數據的外掛，一旦伺服器被取得 shell，付款頁注入側錄腳本、訂單被篡改、客戶數據被讀取的風險就馬上顯著上升。

共享主機還有一個結構問題：同一個 PHP 工作進程池服務多個網站，CVE-2026-109619 的「舊狀態」正正在同一 worker 下一個請求中出現。這不代表每個共享主機都已出事，但意味着隔離較弱環境，一旦被利用，影響就不一定侷限於單一網站。

我們不會點名個別商戶：跑舊版 PHP 不等於已被入侵，但應自我檢查及向主機商或向託管商查詢其 PHP 版本；並在控制面板或 phpinfo 確認是否 8.2 至 8.5；檢查訪問日誌有無大量 multipart POST 或異常的上傳；開啟 WAF 並確認先解析上傳內容；無法即時修補的店鋪，先封鎖 multipart/form-data（這會影響圖片與檔案上傳，可能影響客服及營運），維護窗口上先完成 PHP 更新。若發現不明管理員帳號、付款頁被改動或訂單異常，應立即隔離網站、保留日誌並通報。

AI 把「發現」壓縮到一週

這次披露最值得注意的，不是漏洞本身，而是發現的方式。Wiz 研究團隊在 8 月 19 日找到第一個問題，前後不到一週，通過檢查漏洞的 Wiz Atlas 配合 Google 的 Gemini 4 Argon 與 OpenAI 的 GPT-5.6 Sol；不過同一個漏洞家族，亦由 Calif 的 Ryan Austin、OpenAI 與 Quarkslab 獨立發現（Cloudflare 部落格，2026 年 10 月 21 日）。一個潛伏十多年而未人為知的 PHP 引擎錯誤， AI 輔助工具鏈在數日內定位——不單改變了攻防節奏，而令人懷疑黑客是否也能利用同樣方式，發現更多漏洞。

從 8 月 24 日報告、10 月 20 日外洩、10 月 21 日修補，中間是協調披露的兩個月；但外洩之後，攻擊者在數小時內就打造好攻擊的 exploit；修補發布前六個多小時，Cloudflare 已錄得多次攻擊。AI 加速了「找漏洞」，也加速了「寫 exploit」速度；可是另一邊廂，修補、測試、部署、驗證的流程，仍然是人手變更管理的速度，黑客不愁沒有對象。

政府關站、企業應變：這次不只是「快點更新」

芬蘭 Valtori 在週三下午開始關閉公共網站，總幹事 Hannu Naumanen 向芬蘭媒體確認，做法是「預防性」；法國多個縣政府網站與 info.gouv.fr 一度離線；荷蘭與丹麥亦有政府站點下線。英國、美國與歐盟的網絡安全機構公開呼籲：無法即時修補的系統，應先離線。

企業層面，Cisco Talos 修補當日發布威脅通告，以 Snort 簽名 67359 與 67360 覆蓋客戶與開源社羣（Cisco Talos，2026 年 10 月 21 日）。Cloudflare 則表示，早於 10 月初開發了 WAF 規則，公開披露前約九小時部署；10 月 21 日 03:02（UTC）起，免費與付費 WAF 客戶均獲保護（Cloudflare 部落格）。Cloudflare 迅速行動救了不少網站，但不是每個組織都在用同一家 CDN，不是每個國家的政府都有能力即時協調。

目前沒有公開證據顯示美國聯邦政府網站因這次漏洞被入侵或下線。大規模關站是預防措施，不是已經失守；但預防措施本身已令公共服務中斷。

WAF 與虛擬補丁：能買時間，買不到安全

對未能即時修補的組織，WAF 與虛擬補丁是最實際緩衝。Sansec 的建議很具體：所有已知觸發路徑都是 multipart/form-data 請求，也就是瀏覽器上傳檔案時用格式；PHP 在應用程式碼之前就解析 body，所以在網頁伺服器層直接拒絕這類請求，可以擋住已知的利用。PHP 官方則建議把 memory_limit 設為 -1（並確保應用程式不能覆寫）、把 post_max_size 降到 8M 或 32M，並在代理層限制請求大小、欄位數量、multipart 分段數量與標頭深度（PHP 官方公告）。

這些措施是「reduce exposure」，不構成完整緩解；PHP 官方明言「There are no complete mitigations, updating is the only safe choice」。原因有三。第一，WAF 要判斷一個 multipart 請求是否惡意，必須深入解析 body；解析深度與效能之間有取捨，繞過邊界、填充與編碼可以令特徵比對失準。第二，WAF 只看得到它終止的那一層；如果流量沒有經過，或經過是未解密的通道，規則就無效。第三，漏洞在引擎，修補才是根治；WAF 規則是針對已知 exploit 的外形，新的變體可以繞過。

WAF 與虛擬補丁買的只是「幾小時到幾日」的緩衝時間，用來完成修補；不是修補替代品，也不該成為不修補藉口。

本站經驗：由 WordPress 到雲端原生

本站過去也走過同一條路。it-square.hk 早年以 WordPress 建立在 LAMP 堆疊上：Linux、Apache、MySQL、PHP。WordPress 好處是快、生態大；壞處是修補永無止境——核心、主題、外掛三層都要更新，任何一個外掛停更，就是一個無人看管入口。安全團隊面對不止一個漏洞，而是幾十個元件和版本矩陣；更新還要擔心相容性。效能是另一個難題：PHP 每個請求都要啟動、查數據庫、組裝頁面，流量一上就加記憶體、加伺服器，成本與複雜度同時上升，成本也是促使 it-square.hk 走向雲源生的理由。

後來 it-square.hk 架構遷移到雲端原生：內容以靜態方式生成、經 CDN 分發，PHP 不再位於請求路徑；數據與服務以受控 API 連接，身分與權限成為主要邊界。這次 PHP2Shell 對本站的影響，正因為請求路徑沒 PHP 大幅降低。我們不是説雲端原生沒漏洞，而是説當攻擊面由一個什麼都能跑的引擎，收窄「幾個明確的服務」，防禦變得較易設計。

我們估計零信任將更有意義。傳統邊界防禦假設「內網可信」， PHP 漏洞的問題正是請求在應用程式之前就被處理；一旦引擎被繞過，內網位置就成為攻擊跳板。零信任的做法是反過來：每次存取都要驗證身分與裝置、最小權限、預設拒絕、加密與記錄。這些原則在雲端原生環境較易落地，身分、網絡與工作負載原本是可以分離、可政策化的物件；單體 LAMP 主機上，往往只能靠 WAF 擋在前面。

給香港機構的保護清單

第一，做一次真正的資產盤點，包括 NAS、內聯網、外包系統與舊虛擬機；PHP 不會只在官方網站上。第二，確認版本與修補狀態：8.2 以下已不在官方支援範圍，需向作業系統或廠商確認回溯修補。第三，無法即時修補的對外系統，先在網頁伺服器層封鎖 multipart/form-data，收緊 post_max_size 與代理層限制；同時安排維護窗口完成 PHP 更新。第四，檢查 WAF 是否覆蓋 multipart 解析與上傳路徑，並要求供應商交代規則更新時間。第五，把「元件生命週期」寫進採購合約：不接受已停止支援 PHP 版本。

這次事件最值得關注，不是一個特別的 CVE ，而是三個變化：AI 壓縮漏洞發現到以日來計算；PHP 長尾令修補追不上漏洞披露； WAF 只能買時間，不保證安全，真正的問題不是「會不會被攻擊」，而修補窗口從幾星期縮短到幾小時，架構與流程是否容許你即時反應。如果你用的是 PHP 架構，是時候認真檢討了。