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）。

更令人憂心的是，攻擊可能早於揭露即已發生。亞馬遜威脅情資團隊指出，其 MadPot 蜜罐網路於 10 月 17 日已觀測到針對 php2shell 的利用嘗試，比公開揭露早四天。

慢霧亦於 PHP 官方預先通告後立即發布安全提醒與防護建議。

這兩個漏洞是什麼？

CVE-2026-109618（記憶體耗盡導致的記憶體損毀）：當 PHP 發生記憶體不足（OOM）時，處理流程中斷，手邊資料僅部分準備完成；清理階段卻將這些半成品視為完整資料，造成記憶體損毀。

CVE-2026-109619（陳舊全域狀態）：請求處理完畢後記憶體雖已釋放，相關狀態卻「仍殘留於原處」；當同一 Worker 程序接手下一請求時，可能在正常初始化前即使用此過期狀態。官方確認此問題可用於攻擊 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 等）建置。合約無漏洞，不等於這些元件具備安全性。

根據慢霧旗下威脅情報系統 MistEye 的統計，在其掃描的 1,488 個加密產業相關網域中，793 個具有明確 PHP 指紋，占比約 53.3%。須特別強調：此僅代表使用 PHP，不代表網站存在漏洞或已被入侵。

1. 平台端：幾類典型風險路徑

前端遭竄改，誘使使用者簽署惡意交易。

若 DeFi、錢包類網站或空投頁伺服器遭入侵，攻擊者可篡改頁面上的 RPC 位址、授權目標、合約位址或簽署提示，將正常交易轉為惡意授權、惡意合約互動或偽造存款流程。攻擊者無需攻破合約，僅需誘導使用者自行簽署惡意授權。

金鑰與憑證外洩。

伺服器遭入侵後，攻擊者可能讀取設定檔、資料庫密碼、API 金鑰、環境變數等。若後端以 PHP 連接節點 RPC 或熱錢包服務，一旦 API 金鑰或會話令牌外洩，恐導致熱錢包資產被轉移，或簽署權限遭濫用。

後端與 API 接管。

交易平臺、NFT 市集、跨鏈橋、支付閘道及節點服務商通常具備營運後端，以及 KYC／風控介面、充值地址分配、提幣審核、工單系統等。攻擊者取得權限後，可能竄改設定、竊取使用者資料、建立高權限帳號，或繞過業務流程。

透過供應鏈橫向移動。

PHP 進程權限通常不等同伺服器最高權限；但若可讀取 CI/CD 金鑰、容器執行時 socket、資料庫憑證或雲端存取權杖，攻擊範圍便可能從單一網頁節點擴及資料庫、建置系統，甚至整體生產帳戶。

付款外掛與第三方服務。

據悉，Binance Pay、Crypto.com Pay、BitPay、CoinGate 及 CoinPayments 等加密支付方案均提供 WooCommerce 整合；未修補的伺服器將面臨嚴重暴露風險。RPC、區塊瀏覽器與資料分析平台等第三方服務，若其後端或營運系統運行於受影響的 PHP 環境，亦可能成為入侵入口。當然，RPC 節點、智慧合約、區塊瀏覽器與錢包本身並不原生依賴 PHP，實際取決於各產品技術棧。

然而須注意：伺服器遭入侵未必等同鏈上資產已遭竊取。從網頁服務 breached 到實際財務損失，取決於攻擊者能否取得敏感憑證、簽署流程、管理權限或使用者互動點。熱錢包是否與網頁層隔離、金鑰是否儲存於 HSM/KMS、權限是否最小化，直接決定潛在損失上限。

2. 一般使用者：需要提領所有代幣嗎？

不需要。

原因很簡單：

此弱點僅影響符合特定條件的伺服器環境，並非所有使用者錢包皆有風險。

瀏覽網站並連接錢包，不等同私鑰外洩；該弱點本身無法直接破解使用者錢包或簽章。

專案使用 PHP 並不表示已被入侵。無需假設所有交易所均已遭駭，更不必因此提領全部資產。使用者真正須留意的是所訪問網站是否已被入侵。使用者無法判斷網站是否已完成修補，故本次事件提醒大眾：切勿盲目信任網站介面。攻擊者亦可能藉此公共關注散播假冒登入頁、偽造賠償入口及惡意錢包連接請求。

若專案正式確認其網站或後端遭入侵，使用者應依公告的實際影響範圍，決定是否暫停互動、檢查異常交易及撤銷可疑授權。若確認簽署私鑰或助記詞已外洩，須視為密鑰遭竊事件處理——僅變更密碼或解除網站連結並不充分。使用交易機器人、自動化執行工具或雲端部署服務的使用者，亦應留意相關服務是否已發布受影響版本或憑證輪替通知。

如何因應

1. 平台與專案團隊：

第一步：盤點資產並盡速升級

全面清查所有公開與內部網路中的 PHP 資產：主機、容器映像檔、Kubernetes 工作負載、舊版 CMS、管理後台、合作夥伴託管環境、第三方外掛程式及託管服務。技術指紋僅供線索參考，不可直接等同「確有漏洞」結論。

升級至 8.2.35／8.3.36／8.4.27／8.5.12 版本，或採用發行版、雲服務商或託管服務商提供的等效修補程式。若仍在使用 8.1 或更早版本，請向廠商申請回溯修補，或儘速遷移。無論「舊環境穩定」或「應用程式更新頻率低」皆無法降低此漏洞風險。

升級後須重建容器映像檔、執行滾動重啟或全面替換 PHP 工作程序，並驗證生產環境中實際處理請求的執行時版本——而非僅檢視建置機器或指令列顯示的版本。

第二步：若暫無法升級該如何處理

首先縮減暴露面以爭取緩衝時間，但此舉無法取代修補：

隔離暴露於公網的 PHP 應用程式，或於入口層加設網路認證與存取控制。

停用非必要檔案上傳，並於 WAF 或 Web 伺服器層拒絕無需的 multipart/form-data 請求。

部分資安建議還包括：設定 memory_limit=-1、停用 session.upload_progress.enabled；PHP 8.5 另須停用 fatal_error_backtraces。此類設定可能影響業務與可用性，務必先行測試，且每次調整後均須重啟所有 PHP 工作程序。

第三步：檢查是否遭入侵並輪替憑證

針對曾暴露於公網的受影響服務，應透過日誌、端點監控及異常網路連線（例如 PHP 程序突發啟動系統指令）進行調查。若發現疑似入侵，須優先保全證據，再依資安事件應變流程處理。

採取最壞情境假設：對未及時修補的伺服器，須輪替 API 金鑰、會話金鑰、TLS 憑證、資料庫密碼、雲端存取權杖、CI/CD 憑證、RPC/API 金鑰、Webhook 密鑰及第三方權杖，並審查是否有異常使用紀錄。

若環境中曾安裝或執行確切受侵版本軟體，僅靠升級或重新安裝並不能證明風險已消除；必須同步調查憑證外洩與持續性後門，必要時重建乾淨環境。

第四步：強化資產管控平面

修補 PHP 不應是唯一動作；更重要的是確保「遭入侵的網頁伺服器不會拖垮資金系統」：

將熱錢包、收款錢包及關鍵簽署服務的私鑰，徹底與網頁節點隔離。採用硬體安全模組（HSM）、多方安全計算（MPC）、專用簽署網路，或最小權限 KMS 政策。

將網頁服務、簽署服務、鏈上節點、資料庫及建置系統，分置於不同網路區段與身分邊界。

發生安全事件期間，暫時收緊提款、白名單地址變更、管理員權限提升、API 金鑰建立及風險控制規則修改等高風險操作，必要時啟用手動審核或延遲生效機制。

針對鏈上自動執行的服務，應依業務需求採用獨立簽署、多重簽署審批、交易金額上限及緊急停機機制。

檢查網站靜態資源、JavaScript 套件、反向代理設定、DNS／CDN 規則與交易構建服務，確認未被插入或替換惡意腳本。

2. 一般使用者：

使用官方入口：近期請盡量透過書籤或官方管道訪問平台，並警惕任何假藉「安全事件」名義發送的連結。

勿僅觀察網域與介面：即使熟悉 dApp 網域，伺服器端仍可能已被入侵者替換頁面腳本、交易參數或 RPC 設定。

簽署前逐項驗證：收款地址、所屬鏈、授權金額、呼叫合約及交易模擬結果；特別留意 approve 與 setApprovalForAll 操作，對無限額授權務必格外謹慎。

警覺「賠償」、「遷移」與「重新驗證」：事件期間可能出現「重新登入」、「錢包重驗證」、「資產遷移」、「領取補償」等提示，切勿僅憑站內彈窗行動，須透過專案多個官方管道交叉查證。

分層管理資產：大額持有使用硬體錢包，日常互動使用限額錢包，並定期清理已授予之權限；如此即便前端或平台遭入侵，單一損失亦有明確上限。

異常時先暫停：若遭遇異常簽署請求、非預期授權提示或可疑網站行為，請立即中止操作，並透過官方管道確認。

結語

PHP2Shell 類免登入遠端程式碼執行漏洞一旦突破 Web 層，可將傳統伺服器入侵轉化為前端投毒、身份冒用、簽署權限濫用、熱錢包風險，甚至供應鏈級別的橫向移動。

對平台而言，首要三件事為：升級至已修補版本、隔離暫無法升級之舊版環境、審計金鑰與資產管控平面；升級後，應將入侵跡象搜尋納入事件響應流程。對使用者而言，此期間宜減少對頁面介面的盲目信任，每次簽署前務必多加檢視；但亦無需過度恐慌：漏洞存在不等於資產必然受脅，伺服器遭入侵亦未必導致鏈上資金流失；真正決定風險規模的，是攻擊者取得哪些憑證、這些憑證具備多少權限，以及專案能否迅速隔離並撤銷相關權限。對 Web3 專案而言，安全建設不僅在於設法防止攻擊發生，更須思考：當某元件確實遭攻陷時，能否將影響侷限於局部，避免風險擴散至核心業務與資產操作。

原文連結