首頁

PHP 爆出「互聯網級」高危漏洞，Web3 的「鏈下軟肋」該怎麼補？

閱讀本文需 19 分鐘

PHP 緊急修復兩個 CVSS 9.2 分遠程代碼執行漏洞，影響 5.4 至 8.5.11 版本，細節提前洩露且已被利用。約 53% 的加密行業域名使用 PHP，Web3 平台需盡快升級。

原文標題：《PHP 爆出「網際網路級」高危漏洞，Web3 的「鏈下軟肋」該怎麼補？》
原文作者：慢霧安全團隊

發生了什麼

10 月 21 日，PHP 專案發布緊急安全更新，修復 CVE-2026-109618 和 CVE-2026-109619 兩個可導致未認證遠端程式碼執行(RCE) 的嚴重漏洞；二者均被評為 CVSS v4.0 9.2 分。PHP 官方明確表示，修復前，所有對外提供 Web 服務的 PHP 安裝都可能受到影響。

10 月 20 日，漏洞細節在官方披露前就已洩露，補丁尚未發布。PHP 安全團隊只好把緊急版本從原定的 10 月 22 日提前到 10 月 21 日 14:00 (UTC) 發布。

更值得警惕的是，攻擊可能比披露更早。Amazon 威脅情報團隊報告稱，他們在 10 月 17 日就在自家 MadPot 蜜罐網路裡觀察到了針對 php2shell 的利用嘗試，比公開披露早了四天。

慢霧(SlowMist) 也在 PHP 官方預告發布後第一時間發出了安全提醒和建議。

兩個漏洞分別是什麼

CVE-2026-109618（OOM 記憶體損壞）：PHP 記憶體耗盡時，處理流程會被中斷，這時手上的資料只準備了一半。收尾清理時，PHP 卻把這些半成品當成完整資料來用，結果記憶體就亂了套。

CVE-2026-109619（陳舊全域狀態）：一個請求處理完，記憶體已經釋放了，但相關的狀態還「留在原地」。同一個工作進程接手下一個請求時，可能在正常初始化之前就用上這份過期狀態。官方已確認，可以藉此攻擊 PHP-FPM 並實現遠端程式碼執行。

從攻擊路徑看，這類漏洞危險的地方在於，攻擊者不需要先拿到站點帳號，也不用突破業務層的登入、權限或 API Key 驗證。向暴露在公網的 PHP 應用發一個構造好的請求，就可能以 Web 服務進程的權限執行任意程式碼。

影響範圍：PHP 5.4 至 8.5.11 均受影響。修復版本為 8.5.12、8.4.27、8.3.36 和 8.2.35。PHP 8.1 及更早版本已停止上游常規支援，不能指望常規渠道出補丁，應遷移到仍受支援的版本。

為什麼全世界都緊張？

因為 PHP 實在太普遍了。據 W3Techs 統計，在能識別伺服器語言的網站裡，69.3% 用的是 PHP。WordPress、WooCommerce、Magento 這些大家熟悉的系統，底下都是它。

各國的反應也說明了問題——荷蘭國家網路安全中心曾預防性關閉網站；韓國總統辦公室召開緊急網路安全會議，政府上調了網路安全警報級別。

另外，據報導，北韓幾乎所有官方網站，包括官方媒體和政府入口網站，已離線超過 24 小時，目前尚未得知是否與該漏洞事件有關。

對 Web3 的影響

這不是一個只關乎傳統網站維運的問題。對 Web3 而言，鏈上合約即使沒有漏洞，但圍繞合約運轉的大量「鏈下環節」，包括前端頁面、API、託管錢包、簽名服務、空投領取頁、營運後台和資料服務，很多是用 PHP 搭的（WordPress、WooCommerce、Magento 等）。合約本身沒有漏洞，也不代表這些環節安全。

據慢霧(SlowMist) 旗下威脅情報系統 MistEye 統計，其掃描的 1488 個加密行業相關網域中，793 個具有直接 PHP 指紋，約為 53.3%。需要強調，這只說明用了 PHP，不代表這些網站有漏洞或已被攻破。

1. 平台方：幾條典型的風險路徑

前端被篡改，用戶被誘導簽名。

如果 DeFi、錢包類網站或空投頁的伺服器被控制，攻擊者可以替換頁面裡的 RPC 地址、授權對象、合約地址或簽名提示，把一筆正常交易變成惡意授權、惡意合約交互，或假充值流程。攻擊者不必攻破合約，只要讓用戶自己簽下一筆惡意授權。

密鑰與憑證洩露。

伺服器被控制後，攻擊者可能讀取配置文件、資料庫密碼、API Token、環境變量等。如果後端用 PHP 對接節點 RPC 或熱錢包服務，API Key、會話令牌一旦洩露，就可能升級為熱錢包資產被轉移或簽名權限被濫用。

後台與 API 被接管。

交易平台、NFT 市場、跨鏈橋、支付網關和節點服務商通常有運營後台，還有 KYC/風控接口、充值地址分配、提現審核、工單系統等。攻擊者拿到權限後，可能篡改配置、盜取用戶數據、創建高權限賬號，或繞過業務流程。

供應鏈橫向移動。

PHP 進程的權限通常不等於伺服器的最高權限，但如果它能讀到 CI/CD 密鑰、容器運行時 socket、資料庫憑據或雲訪問令牌，攻擊範圍就可能從一台 Web 節點擴展到資料庫、構建系統，甚至整個生產賬號。

支付插件與第三方服務。

據了解，Binance Pay、Crypto.com Pay、BitPay、CoinGate、CoinPayments 等加密支付方案都有 WooCommerce 集成，伺服器沒修補就有嚴重暴露風險。RPC、區塊瀏覽器、數據分析平台等第三方服務，如果後台或運維系統跑在受影響的 PHP 環境上，也可能成為入口。當然，RPC 節點、智能合約、區塊瀏覽器和錢包本身並不天然依賴 PHP，要看具體產品的技術棧。

但需要注意的是，伺服器被攻陷，不等於鏈上資產一定被盜。從 Web 服務被入侵到真正損失資金，中間還要看攻擊者能不能接觸到敏感憑證、簽名流程、管理權限或使用者互動環節。熱錢包是否與 Web 層隔離、金鑰是否放在 HSM/KMS 裡、權限是否最小化，直接決定損失的上限。

2. 普通使用者：要不要把幣提走？

不需要。

原因很簡單：

這次漏洞影響的是滿足特定條件的伺服器環境，不意味著所有使用者的錢包都有風險。

瀏覽網站、連接錢包，與私鑰洩露不是一回事。漏洞本身並不能直接破解使用者的錢包或簽名。

某個專案可能用了 PHP，不代表它已經出事。沒有理由假設每個交易平台都已被入侵，更不必因此提走全部資產。使用者真正要警惕的，是自己訪問的網站是否已被攻陷。使用者沒辦法判斷一個網站有沒有打補丁，所以這輪事件是個提醒：不要盲目信任網站介面。攻擊者還可能借輿論熱度傳播假登入頁、假補償入口、惡意的錢包連接請求。

如果專案官方確認網站或後台遭入侵，就按公告披露的實際影響判斷是否暫停互動、檢查異常交易、撤銷可疑授權。如果確認簽名私鑰或助記詞已洩露，要按金鑰洩露事件處理，光改密碼或斷開網站連接是不夠的。用交易機器人、自動化執行工具或雲端部署服務的使用者，也要留意相關服務是否發布了受影響版本或憑證輪換通知。

如何應對

1. 平台與專案方：

第一步：摸清家底，儘快升級

盤點所有公網和內網的 PHP 資產：主機、容器映像、Kubernetes 工作負載、遺留 CMS、管理後台、合作方託管環境、第三方外掛和託管服務。技術指紋只能當線索，不能直接當作「確認有漏洞」的結論。

升級到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12，或採用發行版、雲廠商、託管服務商提供的等效補丁。使用 8.1 及更早版本的，要向供應商要 backport 或儘快遷移。「舊環境穩定」「應用不常更新」都不能降低這個漏洞的風險。

升級後重建容器鏡像、滾動重啟或替換所有 PHP 工作進程，並核對線上實際處理請求的運行時版本，而不只是構建機或命令行裡的版本。

第二步：暫時沒法升級怎麼辦

先把暴露面縮小，爭取時間，但這不能替代補丁：

隔離公網暴露的 PHP 應用，或在入口層加網絡認證與訪問控制。

關閉不必要的文件上傳，在 WAF 或 Web 服務器層拒絕不需要的 multipart/form-data 請求。

部分安全建議還包括：設置 memory_limit=-1、關閉 session.upload_progress.enabled，PHP 8.5 上再關閉 fatal_error_backtraces。這些配置有業務和可用性上的副作用，要先測試，每次改動後重啟所有 PHP worker。

第三步：查有沒有被入侵，並清理憑證

對曾暴露在公網的受影響服務，結合日誌、終端監測和異常網絡連接排查，比如 PHP 進程突然去啟動系統命令。發現疑似入侵，先保留證據，再按事件響應流程處置。

假設最壞情況：對未及時修補的服務器，輪換 API 密鑰、會話密鑰、TLS 證書、數據庫密碼、雲訪問令牌、CI/CD 憑據、RPC/API Key、Webhook 密鑰和第三方 Token，並核查是否有異常使用記錄。

如果環境裡裝過或運行過已確認被污染的軟件版本，光升級或重裝不能說明風險已消除，還要排查憑證洩露和持久化後門，必要時重建一個乾淨的環境。

第四步：守住資產控制面

補 PHP 不應該是唯一的動作。更要保證「一台 Web 機被攻陷，不會連累資金系統」：

把熱錢包、歸集錢包和關鍵簽名服務的私鑰，從 Web 節點上徹底隔離。使用 HSM、MPC、專用簽名網路或最小權限的 KMS 策略。

把 Web 服務、簽名服務、鏈上節點、資料庫和建置系統放進不同的網路分段與身分邊界。

事件期間臨時收緊高風險操作，如提現、地址白名單變更、管理員提權、API Key 建立、風控規則修改，必要時啟用人工複核或延遲生效。

鏈上自動執行的服務，可根據業務採用獨立簽名、多簽審批、交易額度限制和緊急停用機制。

檢查網站靜態資源、JavaScript 包、反向代理配置、DNS/CDN 規則和交易建構服務，確認沒有被插入惡意腳本或被替換。

2. 普通使用者：

走正規入口：近期盡量透過書籤或官方管道訪問平台，警惕任何借「安全事件」名義發來的連結。

別只看域名和介面：就算是熟悉的 dApp 域名，頁面腳本、交易參數、RPC 配置也可能被伺服器端的入侵者替換。

簽名前逐項核對：接收地址、所在鏈、授權額度、調用的合約和交易模擬結果。尤其小心 approve 和 setApprovalForAll，對無限額度授權更要謹慎。

警惕「補償」「遷移」「重新驗證」：事件期間可能冒出「重新登入」「重新驗證錢包」「遷移資產」「領取補償」之類的提示。不要只憑站內彈窗操作，要從專案官方的多個管道交叉核實。

給資產分層：用硬體錢包保管大額資產，日常互動用單獨的、限額的錢包，並定期清理授權。這樣即使某個前端或平台出事，單次損失也有上限。

有異常先停手：遇到異常的簽名請求、沒預料到的授權提示，或網站行為不對勁，先暫停，再透過官方管道核實。

最後想說

PHP2Shell 這類免登入的遠端程式碼執行漏洞，一旦突破 Web 層，傳統的伺服器入侵就可能演變成前端投毒、身分冒用、簽名權限濫用、熱錢包風險，甚至供應鏈層面的橫向滲透。

對平台來說，最優先的事有三件：升級到已修復版本，隔離暫時無法修補的老舊環境，審計密鑰與資產控制面。升級之後，還要把排查入侵跡象當作事件回應的一部分。對使用者來說，這段時間要少一點對頁面介面的盲目信任，簽每一筆之前多看一眼。但也別過度恐慌：漏洞存在，不等於資產一定受威脅；伺服器失陷，也不一定導致鏈上資金損失。真正決定風險大小的，是攻擊者能拿到哪些憑證、這些憑證有多大權限，以及專案能多快隔離並撤銷這些權限。對 Web3 專案來說，安全建設不僅要想辦法阻止攻擊發生，更要考慮：某個元件真被攻陷時，能不能把影響限制在局部，不讓風險蔓延到核心業務和資產環節。