高市早苗直呼緊急的PHP危機，一般使用者需要做何防備？

本文來自：Decrypt

編譯｜Odaily 星球日報（@OdailyChina）；譯者｜Moni

編者按：PHP 近日曝出兩項嚴重安全漏洞，CVSS v4 評分均達 9.2 分，攻擊者無需登入即可在受影響伺服器上執行惡意程式碼，甚至完全接管伺服器。芬蘭、法國、荷蘭等多國已採取網站臨時下線等防範措施，PHP 官方也緊急發布修復版本。此次漏洞涉及多個 PHP 舊版本，安全機構警告，補丁公開後可能迅速引發大規模攻擊。

昨晚，日本首相高市早苗在 X 上發布「需要大家緊急應對的重大請求」，提示 PHP 相關風險。

本文將梳理漏洞原理、影響範圍及事件進展，並解析網站營運者和普通加密用戶應採取的應對措施，由 Odaily 星球日報編譯。

但凡你這兩天上過網，大概率已經刷到了這場網路恐慌：一項嚴重漏洞正威脅著全球幾乎所有網站——芬蘭宣布關閉政府網站，美國國家安全局（NSA）建議所有使用 PHP 的組織關閉其網站，荷蘭和法國也採取了同樣的措施。

然而，這並不是一場網路戰，而是 PHP 被爆出兩大安全漏洞。

PHP 是運行在網站伺服器端的後台軟體，你可以把伺服器是一台儲存網站內容、並根據用戶請求生成網頁的電腦，據 WordPress 安全公司 Wordfence 介紹，每個 WordPress 網站背後都有一台運行 PHP 的伺服器。

順便說一句，Wordfence 自己的網站也宕機了。

PHP 漏洞為什麼會讓人擔憂？實際上，相關漏洞可以讓陌生人在無需登入的情況下，直接在伺服器上執行自己的命令。安全行業將這類漏洞稱為「未授權遠端程式碼執行」（Unauthenticated Remote Code Execution，RCE）。

用更通俗的話說，就是「現在，別人可以替你操控伺服器了」。

如果伺服器儲存著你的帳戶資訊、地址或訂單歷史，那麼這些資料也可能落入攻擊者手中。網路託管服務商 GoDaddy 警告稱，這些漏洞可能被用於竊取資料、竄改網站頁面，允許攻擊者透過網際網路在受影響的伺服器上執行自己的程式碼，進而導致資料被盜、甚至完全控制伺服器。

PHP 官方發布了什麼消息？

負責資助 PHP 語言開發的非營利組織 PHP 基金會（PHP Foundation）已發出警報：

PHP 安全團隊提前通知：計劃於 2026 年 10 月 21 日（週三）14:00 UTC 發布安全更新，其中包含兩個嚴重漏洞，兩者的 CVSS v4 評分均為 9.2，建議 PHP 用戶提前做好更新準備。如果相關細節提前公開，或出現漏洞正在遭到主動利用的證據，更新可能提前發布。」

這裡的 9.2 分來自通用漏洞評分系統（CVSS），該系統會根據漏洞能否輕易透過網際網路觸達、可能造成多大損害等因素，評估漏洞的危險程度。評分範圍為 0 至 10 分，9.0 分及以上即被歸類為嚴重漏洞。因此，在沒有達到滿分 10 分的情況下，這兩項漏洞的危險程度已經相當高。

週三 PHP 提前幾分鐘發布了修復版本，分別為 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，同時確認此次漏洞影響 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed 等處理 Web 請求的 PHP 環境，其中 Apache mod_php 風險尤為突出，攻擊可在應用程式程式碼運行前觸發。

然而，官方安全公告毫不含糊地強調：「強烈建議所有 PHP 用戶立即更新。」

但發布修復程式，並不意味著所有用戶都已經完成修復，因此仍需保持警惕。

這些漏洞是如何運作的？

第一個漏洞 CVE-2026-109618 出現在 PHP 處理請求時記憶體耗盡的情況下。此後，PHP 可能會將一份尚未完整建構的資料當作已經完成的資料來處理。

第二個漏洞 CVE-2026-109619 則會導致某個訪問者請求留下的殘餘資料，在本應被清除後仍然滯留在記憶體中，使後續請求可能受到這些殘餘資料的影響。

你可以把這種情況想像成一名廚師，始終在讀取已經被扔進垃圾桶的點菜單，可如果有人往垃圾桶裡塞進一張偽造的菜單，廚師就會照著上面的內容做菜。在本次漏洞中，「菜單」就是攻擊者的惡意程式碼，而伺服器會執行這些程式碼。

PHP 表示，使用一種常見 Apache 配置方式 mod_php 的伺服器面臨的風險最高。在這種配置下，已經演示的攻擊甚至可以在「任何應用程式程式碼運行之前」執行。

換句話說，網站自身的防禦機制，例如登入頁面和 WordPress 安全外掛，甚至還沒來得及啟動。

PHP 基金會的研究人員指出，PHP 的上傳進度追蹤功能是已經確認的一種攻擊入口。該功能用於追蹤檔案上傳的進度，預設啟用至今已有十多年，但實際上很少有網站真正使用它。

漏洞資訊洩露，攻擊隨後出現

這些漏洞的相關資訊原本不應該這麼早公開。實際上，本週二就有人在 Hacker News 論壇發帖稱，兩項 PHP 漏洞原計劃於當週週四披露，同時承認自己「除了『消息來源：信我就對了，兄弟』之外，沒有任何證據」。

事實證明，這位網友說對了。

安全公司 watchTowr 確認，這兩項漏洞確實存在，而且當時仍處於披露禁令期（embargo），也就是在修復方案準備就緒之前，各方約定暫不公開漏洞細節。隨後，PHP 將更新發布時間提前了一天。

Cloudflare 首席技術官 Dane Knecht 週三凌晨在 X 平台發文稱：「我們已經觀察到早期攻擊開始出現，並正在隨著新攻擊路徑的出現，不斷更新緩解措施。」

這條消息發布時，距離補丁正式發布還有近六個小時。

Cloudflare 隨即向所有客戶推送了緊急防火牆規則，透過過濾器攔截已知攻擊模式。不過，Dane Knecht 強調，這些措施「只能作為臨時應對手段」。

各國政府緊急按下關閉鍵

據芬蘭公共廣播公司 Yle 報導，芬蘭國家 IT 中心 Valtori 出於預防目的，開始將公共網路服務下線。荷蘭國家網路安全機構也關閉了自己的網站。

法國方面，內政部表示，在相關框架的發布方推出安全補丁之前，各省政府網站已「暫時下線」。

歐盟網路應急響應團隊 CERT-EU 則建議，對於暫時無法安裝補丁的組織，應「考慮將面向網際網路的應用程式與公共網路隔離，直至修復方案可用」。

隨後，澳洲、日本和英國的相關機構也發布了大致相同的建議。

用通俗語言表達，就是「拔網路線」。

X 平台上的一些熱門帖子聲稱，PHP「自 2004 年以來的所有版本」都存在漏洞。

這一說法源自早期估計，即 PHP 5 及之後的所有版本均受到影響。但 CERT-EU 承認，這一估計依據的是社群媒體上的帖子。

電商安全公司 Sansec 則認為，受影響的版本範圍從 PHP 5.4 開始，涵蓋此後的版本。這意味著漏洞影響範圍最早可追溯至 2012 年，而不是 2004 年。不過，這仍然涉及相當古老的軟體版本。

PHP 官方目前僅為 PHP 8.2 及更新版本提供正式發布的版本更新。因此，「舊版本沒有修復方案」這一說法有一部分是正確的。

鑑於此次漏洞的嚴重程度，PHP 安全團隊還為 PHP 7.4、8.0 和 8.1 發布了精簡的原始碼補丁。各 Linux 發行版也正在將修復程式回移至各自維護的版本中。

安全公司 Mallory 統計發現，截至 10 月 20 日，約有 88.4 萬台面向網際網路、對外顯示 PHP 8.1 或更早版本的主機。這些主機約占公開顯示版本資訊的 150 萬台主機的 59%。

由於一台共享主機可以承載許多網站，因此實際受影響的網站數量可能更高。

一些網路帖子還將 Node.js 一併列入受影響範圍。Node.js 是另一種不同的 Web 技術，只是恰好也安排在同一天發布一項與此次事件無關的安全更新。時間撞車造成了混淆。

即便已經發布補丁，也不意味著所有伺服器都能立即完成更新。

PHP 基金會在聲明中表示：「如果你依賴由志願者維護的 https://rpms.remirepo.net，我們強烈建議你現在就切換到 Linux 發行版官方軟體包，或者自行從原始碼建構，以便立即套用更新。該軟體包倉庫今天不會發布更新。」

該聲明指的是一個頗受歡迎的軟體包來源，由志願者維護，主要面向採用 Red Hat 風格的 Linux 伺服器。

加密用戶需要擔心嗎？

坦率滴說，普通用戶不必馬上恐慌，但也不應該對此掉以輕心。

例如，網站遭到入侵，並不需要直接攻擊區塊鏈，就能讓你的錢包資產被盜。

2024 年，攻擊者曾將 DeFi 協議 Compound 和 Celer 的前端頁面重定向至惡意頁面，從而誘導用戶連接錢包並盜取資產。2025 年，Curve Finance 也遭遇了類似攻擊。

不過，這些事件屬於 DNS 劫持，而非 PHP 漏洞，但其攻擊手法具有相似之處：網站看起來正常，網址也沒有異常，但你點擊的「批准」按鈕，卻可能將代幣發送到其他地址。

如果伺服器遭到入侵，攻擊者同樣可以向用戶提供這種惡意頁面。在利用零日漏洞方面，駭客往往能夠迅速想出各種攻擊手段。

與此同時，發現此類漏洞也變得越來越容易。先進的人工智慧模型正越來越多地被用於發現軟體漏洞。6 月，專家曾向 Decrypt 表示，隨著這些工具逐漸普及，未來可能會出現更多漏洞。

接下來會發生什麼？用戶應該怎麼做？

普通用戶應該恐慌嗎？

你的手機、瀏覽器和筆記型電腦並不都需要安裝 PHP 補丁，真正需要採取行動的是營運你所訪問網站的相關人員。如果你營運著一個網站，應聯繫主機託管服務商，確認 PHP 是否已經更新。不要以為 WordPress 會自動替你完成這項工作：Wordfence 已經警告，自動更新機制不會自動套用此次修復，並建議網站所有者查明究竟由誰負責更新伺服器上的 PHP。

如果您使用的是 PHP 8.2，那麼您剛剛獲得的修復程式可能是您最後的修復程式之一：該版本將於 2026 年 12 月 31 日停止維護，之後將不再獲得安全補丁。此外，仍在使用 PHP 8.1 或更早版本的用戶，需要制定升級計畫。

PHP 基金會公布補丁會有一定程度的幫助，但是問題是，一旦補丁公開，攻擊者就可以對比修復前後的程式碼，準確找出哪些問題得到了修復。網路安全公司 Sansec 的取證團隊表示，預計「補丁發布後 15 分鐘內就會開始出現大規模攻擊」。

2024 年 6 月，另一項 PHP 漏洞公開後，Akamai 在 24 小時內就發現了針對其誘捕伺服器的漏洞利用嘗試。

正如 PHP 核心開發者 Gina Peter Banyard 在 Mastodon 上表示：「我唯一能說的是，唯一的緩解措施就是為 PHP 安裝補丁或升級 PHP。遺憾的是，我知道得太多了。」