金色財經
作者：Lisa
編輯：77
10 月 21 日，PHP 項目發布緊急安全更新，修復 CVE-2026-109618 和 CVE-2026-109619 兩個可導致未認證遠程代碼執行(RCE) 的嚴重漏洞；二者均被評為 CVSS v4.0 9.2 分。PHP 官方明確表示，修復前，所有對外提供 Web 服務的 PHP 安裝都可能受到影響。
(https://www.php.net/index.php#2026-10-20-1)
10 月 20 日，漏洞細節在官方披露前就已泄露，補丁尚未發布。 PHP 安全團隊只好把緊急版本從原定的 10 月 22 日提前到 10 月 21 日 14:00 (UTC) 發布。
更值得警惕的是，攻擊可能比披露更早。Amazon 威脅情報團隊報告稱，他們在 10 月 17 日就在自家 MadPot 蜜罐網路里觀察到了針對 php2shell 的利用嘗試，比公開披露早了四天。
(https://aws.amazon.com/cn/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)
慢霧(SlowMist) 也在 PHP 官方預告發布後第一時間發出了安全提醒和建議。
(https://x.com/SlowMist_Team/status/2112736351141740754)
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 這些大家熟悉的系統，底下都是它。
各國的反應也說明了問題——荷蘭國家網路安全中心曾預防性關閉網站；韓國總統辦公室召開緊急網路安全會議，政府上調了網路安全警報級別。
(https://x.com/ncsc_nl/status/2112874187719385243)
另外，據報導，朝鮮幾乎所有官方網站，包括官方媒體和政府門戶網站，已離線超過 24 小時，目前尚未得知是否與該漏洞事件有關。
這不是一個只關乎傳統網站運維的問題。對 Web3 而言，鏈上合約即使沒有漏洞，但圍繞合約運轉的大量"鏈下環節"，包括前端頁面、API、託管錢包、簽名服務、空投領取頁、營運後台和數據服務，很多是用 PHP 搭的（WordPress、WooCommerce、Magento 等）。合約本身沒有漏洞，也不代表這些環節安全。
據慢霧(SlowMist) 旗下威脅情報系統 MistEye 統計，其掃描的 1488 個加密行業相關域名中，793 個具有直接 PHP 指紋，約為 53.3%。需要強調，這隻說明用了 PHP，不代表這些網站有漏洞或已被攻破。
如果 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 里、權限是否最小化，直接決定損失的上限。
這次漏洞影響的是滿足特定條件的服務器環境，不意味著所有用戶的錢包都有風險。
瀏覽網站、連接錢包，與私鑰泄露不是一回事。漏洞本身並不能直接破解用戶的錢包或簽名。
某個項目可能用了 PHP，不代表它已經出事。沒有理由假設每個交易所都已被入侵，更不必因此提走全部資產。
用戶真正要警惕的，是自己訪問的網站是否已被攻陷。用戶沒辦法判斷一個網站有沒有打補丁，所以這輪事件是個提醒：不要盲目信任網站界面。攻擊者還可能借輿論熱度傳播假登錄頁、假補償入口、惡意的錢包連接請求。
如果項目官方確認網站或後台遭入侵，就按公告披露的實際影響判斷是否暫停交互、檢查異常交易、撤銷可疑授權。如果確認簽名私鑰或助記詞已泄露，要按密鑰泄露事件處理，光改密碼或斷開網站連接是不夠的。用交易機器人、自動化執行工具或雲部署服務的用戶，也要留意相關服務是否發布了受影響版本或憑證輪換通知。
盤點所有公網和內網的 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 規則和交易構造服務，確認沒有被插入惡意腳本或被替換。
走正規入口：近期儘量通過書籤或官方渠道訪問平台，警惕任何借"安全事件"名義發來的鏈接。
別只看域名和界面：就算是熟悉的 dApp 域名，頁面腳本、交易參數、RPC 配置也可能被服務器端的入侵者替換。
簽名前逐項核對：接收地址、所在鏈、授權額度、調用的合約和交易模擬結果。尤其小心 approve 和 setApprovalForAll，對無限額度授權更要謹慎。
警惕"補償"」遷移"」重新驗證"：事件期間可能冒出"重新登錄"」重新驗證錢包"」遷移資產"」領取補償"之類的提示。不要只憑站內彈窗操作，要從項目官方的多個渠道交叉核實。
給資產分層：用硬體錢包保管大額資產，日常交互用單獨的、限額的錢包，並定期清理授權。這樣即使某個前端或平台出事，單次損失也有上限。
有異常先停手：遇到異常的簽名請求、沒預料到的授權提示，或網站行為不對勁，先暫停，再通過官方渠道核實。
PHP2Shell 這類免登錄的遠程代碼執行漏洞，一旦突破 Web 層，傳統的服務器入侵就可能演變成前端投毒、身份冒用、簽名權限濫用、熱錢包風險，甚至供應鏈層面的橫向滲透。
對平台來說，最優先的事有三件：升級到已修復版本，隔離暫時無法修補的老舊環境，審計密鑰與資產控制面。升級之後，還要把排查入侵跡象當作事件響應的一部分。對用戶來說，這段時間要少一點對頁面界面的盲目信任，簽每一筆之前多看一眼。
但也別過度恐慌：漏洞存在，不等於資產一定受威脅；服務器失陷，也不一定導致鏈上資金損失。真正決定風險大小的，是攻擊者能拿到哪些憑證、這些憑證有多大權限，以及項目能多快隔離並撤銷這些權限。對 Web3 項目來說，安全建設不僅要想辦法阻止攻擊發生，更要考慮：某個組件真被攻陷時，能不能把影響限制在局部，不讓風險蔓延到核心業務和資產環節。
來源：金色財經
發佈者對本文章的內容承擔全部責任
在投資加密貨幣前，請務必深入研究，理解相關風險，並謹慎評估自己的風險承受能力。不要因為短期高回報的誘惑而忽視潛在的重大損失。
暢行幣圈交易全攻略，專家駐群實戰交流
▌立即加入鉅亨買幣實戰交流 LINE 社群（點此入群）
不管是新手發問，還是老手交流，只要你想參與加密貨幣現貨交易、合約跟單、合約網格、量化交易、理財產品的投資，都歡迎入群討論學習！
上一篇
下一篇
