什麼是 PHP2Shell 漏洞？誰需要注意？

2026 年 10 月 21 日，PHP 官方緊急發布了安全更新，修補兩個被命名為 PHP2Shell 的重大漏洞（CVE-2026-109618 與 CVE-2026-109619）。這兩個漏洞存在於 PHP 執行環境本身（不是任何外掛、框架或套件），影響範圍從 2012 年的 PHP 5.4 一路到最新的 PHP 8.5，估計波及全球近 70% 的網站。攻擊者無需任何帳號密碼，就能透過精心構造的請求在伺服器上執行任意程式碼，取得網站主機的控制權。本文將說明 PHP2Shell 的技術原理、嚴重性、誰該立即注意，以及完整的修補方案。

一、PHP2Shell 是什麼？

PHP2Shell 是安全廠商 Wiz 給這對漏洞取的名字，意義很直白：攻擊者利用 PHP 的缺陷，從遠端取得伺服器的 shell（命令執行權限）。

它包含兩個獨立但同樣致命的漏洞：

兩個漏洞的共同點：都在 PHP 解析請求階段就觸發，早於應用程式碼與任何身分驗證。這代表即使你的網站沒有任何公開的表單或上傳功能，只要伺服器用 PHP 服務請求，攻擊面就存在。

漏洞怎麼被發現的？

這對漏洞有個劃時代的背景：它是由 AI 輔助發現的。2026 年 8 月，安全研究員 Ryan Austin（隸屬 Calif，參與 OpenAI 的「Patch the Planet」計畫）與 Wiz 的研究團隊（使用 Gemini 4 Argon、GPT-5.6 Sol 與自家的 Wiz Atlas 工具）各自獨立用 AI 找到了這兩個深藏十幾年的記憶體安全缺陷。研究人員追蹤發現，問題最早可追溯到 PHP 5.4（2012 年發布），其中一個相關的記憶體錯誤其實在 2024 年的稽核中就被 PHP 核心開發者發現過，但因為當時沒有可行的攻擊手法而未獲優先處理——直到 AI 證明了它的可利用性。

事件時間軸

• 10/20：漏洞細節在正式發布前提前洩漏（Hacker News、watchTowr、一段誤發的 PoC 影片），PHP 官方提前公告「緊急更新即將推出」
• 10/21 03:02：Cloudflare 的 WAF 防護規則上線
• 10/21 13:34：PHP 官方在 GitHub 發布兩份安全公告（比原定時間提前 26 分鐘）
• 10/21 14:00：修補版本正式發布
• 洩漏後數小時內，PoC 與技術分析開始在網路上流傳；Amazon 的威脅情資更發現早在 10/17（公告前四天）就有攻擊嘗試的跡證

荷蘭眾議院、英國 NCSC 等政府機構在修補期間預防性將網站下線，可見業界對它的戒備等級。

二、技術原理（白話版）

CVE-2026-109618（OOM 記憶體損毀）

PHP 在解析 multipart POST 請求（例如檔案上傳）時有每個請求的記憶體上限。攻擊者送出一個刻意耗盡記憶體的請求，PHP 在「解析到一半」的狀態下被強制中止，留下未完成初始化的內部資料。在後續清理階段，PHP 會誤解攻擊者可影響的記憶體內容，導致執行攻擊者指定的指令——此時 PHP 還沒跑到你的應用程式碼，更別說登入驗證。

CVE-2026-109619（殘留全域狀態）

第一個請求觸發致命錯誤，讓某個 PHP worker 留下指向已釋放記憶體的懸空引用。緊接著的第二個請求由同一個 worker 處理，攻擊者利用它重新填塑那塊記憶體。當 PHP 使用到殘留的懸空引用時，執行流程就被引導到攻擊者準備好的指令上。

兩者都屬於記憶體安全（memory safety）問題——這類缺陷是 C 語言家族的經典宿疾，PHP 底層正是以 C 實作。成功利用後，攻擊者以網頁伺服器行程的權限執行程式碼，竊取憑證、資料庫連線、使用者 Session 與客戶資料都只是時間問題。

三、誰需要注意？

🔴 第一級：自架 PHP 伺服器的管理人

只要你的伺服器用 PHP 服務網頁——無論是 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 還是 LiteSpeed——都在影響範圍內，且 PHP 官方已證實預設設定即可被利用。

檢查方式（在伺服器上執行）：

php -v

對照修補版本：

注意：許多 Linux 發行版（如 Ubuntu）會以 backport 方式將修補包進自家套件而不改版本號，請以發行版的安全公告（例如 Ubuntu USN-8948-1）為準，不要只看 php -v 的數字。

🟠 第二級：使用舊版 PHP（8.1 以下）的站台

PHP 8.1、8.0、7.4 雖然已停止官方維護，但這次官方破例提供了原始碼修補檔。你的選項：

1. 升級到 PHP 8.2 以上（最推薦，一勞永逸）
2. 使用發行版提供的 backport 套件（Debian/Ubuntu 的 LTS 套件通常已收錄修補）
3. 依官方公布的最小修補檔自行重新編譯 PHP（僅適合有編譯經驗的團隊）

🟠 第三級：虛擬主機 / 共享主機的使用者

自己無法控制伺服器的 PHP 版本？立即向主機商確認。大型主機平台（cPanel、CloudLinux 生態）通常會自動套用 backport 更新，但更新時程各家不同——用一封客服工單確認「PHP2Shell 是否已修補」，是你的責任範圍內最有效的一步。

🟡 第四級：WordPress 等 PHP 應用程式的站長

注意一個容易混淆的點：PHP2Shell 是 PHP 執行環境的漏洞，不是 WordPress 的漏洞。升級 WordPress、更新外掛都無法修補它——真正要更新的是主機上的 PHP 本身。若你在共享主機上，請依第三級的建議確認主機商狀態。

🟡 第五級：使用容器部署的團隊

Docker 映像檔裡的 PHP 不會自己更新。重新 pull base image 並 rebuild 所有含 PHP 的映像檔，再重新部署。別忘了檢查那些「很久沒動」的舊映像檔是否仍在線上服務。

🟢 第六級：非 PHP 技術棧（Node.js、Python、.NET 等）

你的服務本身不受影響。但仍建議：檢查對外系統是否有「順手裝的 PHP 工具」（phpMyAdmin 就是 PHP 寫的！）或舊的 PHP 網站遺留在伺服器上——只要主機上有一個未修補的 PHP 行程在服務請求，就是入口。

四、怎麼修補？

唯一的完整解法：更新 PHP

PHP 官方說得很明白：沒有任何設定能完整緩解風險，更新是唯一安全選擇。

sudo apt update && sudo apt upgrade "php*"

sudo dnf update "php*"

更新後重新啟動所有 PHP 相關服務（php-fpm、apache2、nginx 的 FPM socket 等），並確認版本已達安全版號。

無法立即更新時的臨時緩解（僅降低風險，非修補）

PHP 官方公布的臨時性設定（寫在主設定檔、應用程式無法覆寫的位置，改完重啟 PHP 行程）：

• memory_limit = -1（避免攻擊者控制記憶體耗盡時機）
• 調低 post_max_size，且 upload_max_filesize 必須低於 post_max_size

再次強調：這些設定只是爭取時間，不是替代方案。

加分動作

• 若有 WAF / CDN（如 Cloudflare），確認防護規則已啟用——但 Cloudflare 已觀察到攻擊者持續改寫 payload 繞過防火牆規則，WAF 不能取代修補
• 修補後檢查網站檔案是否有被植入的 webshell（尤其修補前就公開曝露的站點）
• 排查伺服器上所有 PHP 行程，別只看主要的網站

五、給 IT 團隊的檢查清單

• ✅ 盤點所有伺服器上的 PHP 版本（含容器、側車、遺留系統）
• ✅ 對照安全版本表，找出所有未修補節點
• ✅ 已在修補範圍內的：透過套件管理員更新 + 重啟服務
• ✅ EOL 版本的：排定升級計畫，過渡期間套用臨時緩解 + 網路層限制
• ✅ 共享主機：向主機商開工單確認
• ✅ 修補後：檢查 webshell 植入痕跡、審視異常請求日誌
• ✅ 建立「重大漏洞緊急修補」SOP（這次從公告到修補只有一天，未來只會更快）

結語

PHP2Shell 的三個啟示值得所有技術團隊記下：第一，執行環境層的漏洞（runtime）影響的是所有跑在上面的網站，與你的應用程式碼品質無關；第二，這次從細節洩漏到 PoC 流傳只花了幾小時，修補窗口比以往任何時候都短——Sansec 甚至預估「修補發布後 15 分鐘內就會開始大規模攻擊」；第三，AI 正在改變攻防兩端的遊戲規則，這對漏洞是 AI 大規模輔助挖掘的里程碑，可以預期未來類似的「AI 找洞 → 緊急修補」事件會成為常態。

如果你的伺服器上有 PHP，這不是「有空再處理」的事——現在就查版本、現在就更新。