- 摩傑斯
- 2026-10-23
PHP 高危漏洞 php2shell：中小企業站點應急修復清單
10月21日，國家資訊安全漏洞共享平臺（CNVD）收錄了 PHP 的兩個嚴重安全漏洞，編號 CVE-2026-109618 與 CVE-2026-109619，業內代號「php2shell」。兩項漏洞的 CVSS v4.0 評分均為 9.2 分，CNVD 綜合評級「高危」。
這不是又一個「記得更新」的常規提醒。它壞在 PHP 直譯器核心的記憶體管理環節——也就是大多數網站跑在最底層的那一層。修復它，只能動伺服器上的 PHP 本身，任何應用層操作都替代不了。
一、危害鏈路：一個請求，整臺伺服器
按官方與多家安全團隊的描述，攻擊路徑相當短：未經身份驗證的遠端攻擊者構造特製的 multipart POST 請求發往目標伺服器，觸發記憶體破壞，最終實現遠端程式碼執行，拿到伺服器控制權。除遠端程式碼執行外，同一漏洞還可被用來發起拒絕服務攻擊、竊取敏感資料。
時間線上還有一段插曲：漏洞資訊在 10 月 20 日提前洩露，PHP 安全團隊被迫確認並公佈釋出時間，而駭客趁機搶在補丁上線前數小時就發起了攻擊。到 10 月 21 日 13:30 UTC，官方修復版本才正式釋出。
換句話說，從資訊洩露到補丁落地，中間存在一個視窗期，而攻擊在那之前就已經開始了。
二、影響範圍：先看清自己在不在這個框裡
受影響的 PHP 版本如下：
| 分支 | 受影響版本 | 修復版本 |
|---|---|---|
| 8.5.x | 低於 8.5.12 | 8.5.12 |
| 8.4.x | 低於 8.4.27 | 8.4.27 |
| 8.3.x | 低於 8.3.36 | 8.3.36 |
| 8.2.x | 低於 8.2.35 | 8.2.35 |
| 8.1 及更早 | 全部（已停止官方支援） | 需升級或依賴 LTS 廠商補丁 |
部署形態上，受影響的不是「用 PHP 寫的網站」，而是所有以 PHP 處理 Web 請求的環境：PHP-FPM、Apache 搭配 mod_php、php-cgi、FrankenPHP、LiteSpeed。其中 Apache mod_php 被官方點名為風險最高的配置——攻擊者可以在任何應用程式碼執行之前就觸發攻擊，一次未認證請求即可。
連帶影響還覆蓋 Magento、WordPress、Drupal、Joomla、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS、OpenCart 等主流 CMS 與框架。所謂「衝擊全球七成網站」，說的不是七成站點會被打，而是底層執行時共享同一個風險面。
三、兩個漏洞分別壞在哪
官方與 CERT 通報給出的機制描述可以壓縮成兩句話。
CVE-2026-109618：出錯時的現場沒收拾乾淨。PHP 用 longjmp() 中止超出 memory_limit 的請求並丟擲 OOM 錯誤。這會在內部請求資料只初始化了一半時直接中斷——比如正在解析一次表單檔案上傳。後續清理流程卻把這份無效資料當作有效資料去釋放，而那塊記憶體裡可能還殘留著攻擊者可控的舊資料。
CVE-2026-109619：上個請求的東西留在了下個請求裡。請求持有的內部狀態，在其後備記憶體被釋放之後仍然存活——例如發生致命錯誤之後。同一個 worker 處理的下一個請求，可能在正常初始化把它重置之前，就用上了這份陳舊狀態。
概括起來：PHP 在「出錯之後把現場收拾乾淨」這件事上做得不夠徹底，而攻擊者有能力把出錯點擺在對自己有利的位置上。
四、現在該做什麼（順序別亂）
第一步，查版本——注意命令列和網站真跑的不是一個東西。
用 php -v 查命令列版本，用 php-fpm -v 或 php-fpm8.3 -v（按實際分支）查網站實際執行的版本。最常見的坑是：命令列查出來已經是 8.3.36，網站實際跑的是 FPM 池裡的 8.3.20，兩邊根本不同步。升級之後，同樣要用 FPM 的方式再複核一遍。
第二步，能升就升。
優先走發行版或 LTS 廠商的官方包，別自己編譯。已經 EOL 的 8.1 及更早版本：找供應商確認有沒有回溯補丁；PHP 官方這次也額外為從原始碼構建的組織提供了 7.4、8.0、8.1 的最小化原始碼 backport。
第三步，補丁打不上就先擋住。
- CVE-2026-109618：在 FPM 池配置或 Apache 配置裡設
memory_limit=-1（用php_admin_value，讓應用層面無法覆蓋），並確認沒有別的層級把有限值又設了回來 - CVE-2026-109619：把面向網際網路的 PHP 應用與公網隔離，直到補丁應用並驗證完成
- 官方列出的臨時手段還包括：臨時下線、關閉會話上傳進度功能、網路訪問限制
這裡要把話說清楚：官方明確說明，**只有升級才是真正的修復**，這些措施只是降低特定攻擊路徑的暴露面，不等於安全。
第四步，升級後必須驗證。重啟 php-fpm 或 apache，再查一次版本。「升了但沒重啟」的假修復，在事故覆盤裡出現的頻率高得離譜。
第五步，回頭查有沒有被摸過。漏洞細節與驗證程式碼已經公開傳播，攻擊門檻很低。補丁之外還要補三件事：更換伺服器賬號、口令、金鑰等憑證；排查日誌裡的異常 multipart POST 與異常子程序；掃一遍 Webshell。
五、一個高頻誤解：更新 WordPress 沒用
WordPress 官方已經明確：這個問題**無法透過應用層更新解決**，站點所有者必須直接更新伺服器實際執行的 PHP 環境。
很多人看到新聞的第一反應是登後臺更新 WordPress、更新外掛——方向錯了。該動的是伺服器上的 PHP 本身。中小企業的站點大多託管在虛擬主機或第三方伺服器上，PHP 版本並不在自己手裡，這種情況該做的是：立刻聯絡服務商確認是否已修補；對方打不了補丁，就要求給出隔離或臨時防護的具體方案與時間。
