PHP2Shell 是 2026 年 10 月 21 日公開的兩個 PHP 遠端程式碼執行漏洞的簡稱，編號為 CVE-2026-109618 與 CVE-2026-109619，兩個都由 PHP 專案評為 CVSS v4.0 9.2。PHP 官方在 10 月 21 日發布 8.5.12、8.4.27、8.3.36、8.2.35 四個修補版本，官方的說法是升級才是唯一完整的解法。網站若跑在 PHP 上，包含 WordPress 這類 PHP 應用，先查 PHP 版本，再要求主機商或維運團隊升級並重啟所有 worker。
本文資料取得日為 2026 年 10 月 22 日，以 PHP 官方公告、GitHub 安全公告、CVE 記錄與發現團隊的文章為準。漏洞細節與各家說法仍在更新，轉用前請回到文末來源再核對一次。
PHP2Shell 是什麼？
PHP2Shell 指的是 CVE-2026-109618 與 CVE-2026-109619 這兩個漏洞。PHP 官方公告把風險描述為「所有處理網頁請求的 PHP 安裝」，包含 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed，其中 mod_php 的風險最高。
項目：官方摘要、CVE-2026-109618：RCE via OOM corruption（記憶體不足處理時的記憶體損壞）、CVE-2026-109619：RCE via stale global state（過期的全域狀態）
項目：CVSS v4.0、CVE-2026-109618：9.2（CRITICAL）、CVE-2026-109619：9.2（CRITICAL）
項目：公開時間、CVE-2026-109618：2026-10-21（GitHub 公告 13:34 UTC，CVE 記錄 13:48 UTC）、CVE-2026-109619：2026-10-21（GitHub 公告 13:34 UTC，CVE 記錄 13:54 UTC）
項目：確認的影響、CVE-2026-109618：以網頁服務帳號身分，未經驗證即可遠端執行程式碼、CVE-2026-109619：未經驗證的記憶體釋放後使用、記憶體內容洩漏與遠端執行程式碼
來源：GitHub php-src 安全公告 GHSA-w8hw-w9fx-j79w 與 GHSA-6wmf-4rv5-p3rp、cve.org 記錄。NVD 另外給了 CVSS v3.1 9.8，PHP 專案給的是 v4.0 9.2。
PHP2Shell 這個名字是誰取的？
名稱的出處沒有查到明確說法。Wiz 與 Calif 在 10 月 21 日發表的文章都用 PHP2Shell 當標題，Cloudflare 的文章寫「known as php2shell」。PHP 官方公告與兩則 GitHub 公告沒有使用這個名稱。Wiz 的文章把 php2shell 描述為他們把兩個漏洞串成的利用腳本名稱。
漏洞的發現者依 CVE 記錄的致謝欄位，列有 Calif 的 Ryan、Wiz 與 OpenAI。
哪些 PHP 版本受影響？
官方 CVE 記錄列出 PHP 8.2、8.3、8.4、8.5 四條版本線，修補前的版本都受影響。發現團隊的說法範圍更大：Wiz 寫「過去十年發布的每個 PHP 版本，至少受其中一個漏洞影響，可追溯到 5.4」，Cloudflare 寫「所有執行 PHP 5.4 或更新版本的網頁伺服器」。
PHP 官方也替已終止支援的版本準備了修補。官方公告寫明，安全團隊為 PHP 7.4、8.0、8.1 提供了「最小原始碼修補（minimal source-backports）」，給自行編譯或沒有長期支援廠商的人使用。因此文章與內部通報不要寫成「只有 8.2 以上受影響」。
PHP 版本線：8.5、官方支援狀態（php.net，2026-10-22 讀取）：安全支援到 2029-12-31、這次修補怎麼拿：升級到 8.5.12
PHP 版本線：8.4、官方支援狀態（php.net，2026-10-22 讀取）：安全支援到 2028-12-31、這次修補怎麼拿：升級到 8.4.27
PHP 版本線：8.3、官方支援狀態（php.net，2026-10-22 讀取）：安全支援到 2027-12-31、這次修補怎麼拿：升級到 8.3.36
PHP 版本線：8.2、官方支援狀態（php.net，2026-10-22 讀取）：安全支援到 2026-12-31、這次修補怎麼拿：升級到 8.2.35
PHP 版本線：8.1、官方支援狀態（php.net，2026-10-22 讀取）：2025-12-31 終止支援，最後版本 8.1.34、這次修補怎麼拿：官方不再出版本，向發行版或長期支援廠商詢問，或使用官方原始碼修補分支
PHP 版本線：8.0、7.4、官方支援狀態（php.net，2026-10-22 讀取）：更早終止支援、這次修補怎麼拿：同 8.1
官方公告對 8.1 及更舊版本的原文是：「PHP 8.1 and older no longer receive updates from the PHP project.」，並建議洽詢發行版或長期支援廠商，或升級到仍有支援的版本。
已經有人利用這些漏洞了嗎？
截至 2026 年 10 月 22 日讀取的資料，美國 CISA 的已知遭利用漏洞目錄（KEV，10 月 21 日版）沒有收錄這兩個 CVE。CISA 在 CVE 記錄上的評估寫「Exploitation: none」，評估時間為 10 月 21 日 14:34 UTC。
另一方面，Cloudflare 在官方部落格寫明，漏洞在正式發布日之前外洩，並且觀察到針對其客戶的攻擊流量，攻擊者也在改寫攻擊內容嘗試繞過防護。這是目前唯一一手的在野攻擊說法。攻擊流量只表示有人在試，不等於已有網站被入侵成功。PHP 官方公告沒有說已遭利用。
Cloudflare 表示，從 10 月 21 日 03:02 UTC 起，使用免費或付費 WAF 的客戶預設已受到防護。WAF 能擋掉部分已知攻擊內容，官方仍說沒有完整的緩解方式，升級才是安全的作法。
企業要做哪幾件事？
先確認哪些系統跑 PHP，再升級並重啟。下表是依官方處置整理的檢查順序，其中「怎麼查」欄屬一般維運做法，實際指令依主機環境而異。
步驟：1、要做什麼：盤點哪些網站與系統跑 PHP、怎麼查或怎麼做：問自己的維運團隊、主機商、外包網站廠商；WordPress 與多數 CMS 都跑 PHP、完成的證據：一張清單：站名、主機商、PHP 版本、負責人
步驟：2、要做什麼：確認每個站的 PHP 版本、怎麼查或怎麼做：主機後台或維運人員回報的版本號；比對上表、完成的證據：每站一個版本號與查詢日期
步驟：3、要做什麼：升級到修補版本、怎麼查或怎麼做：8.5.12、8.4.27、8.3.36、8.2.35；自管主機用套件管理工具，代管主機請主機商處理、完成的證據：升級後的版本號
步驟：4、要做什麼：重啟所有 PHP worker、怎麼查或怎麼做：官方明說要重啟每個 worker，設定與新版才會生效、完成的證據：重啟時間紀錄
步驟：5、要做什麼：8.1 以下的站先決定去向、怎麼查或怎麼做：洽詢發行版或長期支援廠商的修補套件，或規劃升級到仍有支援的版本、完成的證據：書面回覆或排程
步驟：6、要做什麼：留下紀錄、怎麼查或怎麼做：誰在幾月幾日把哪個站升到哪個版本、完成的證據：一份可交給稽核或客戶的紀錄
如果網站交給外包廠商或代管主機維護，向對方問下面三個問題，請對方書面回覆：
我們的網站目前跑哪一個 PHP 版本？
已經升級到上表的修補版本了嗎？升級與重啟的時間是幾月幾日？
如果跑的是 8.1 或更舊版本，修補要怎麼取得、預計哪天完成？
無法立刻升級時，官方給了哪些暫時設定？
官方列出幾項只能降低部分攻擊路徑的設定，同時明說這些設定「不會讓系統變安全（do not make an installation safe）」。下表四項取自官方公告，已逐字對過原文，並對照到各自的漏洞。
對應漏洞：CVE-2026-109618、設定：
memory_limit=-1，最好用應用程式無法覆寫的方式設定，例如 FPM pool 的php_admin_value或 Apache 設定、官方說明的限制：移除可控的記憶體上限失敗路徑，但底層記憶體配置失敗仍可能走到有漏洞的程式碼對應漏洞：CVE-2026-109618、設定：調低
post_max_size：不需要檔案上傳的應用設 8M，需要上傳的設 32M，upload_max_filesize要小於它、官方說明的限制：只縮小攻擊面對應漏洞：CVE-2026-109619、設定：
session.upload_progress.enabled=0並重啟所有 worker，要在請求解析前就生效的設定檔套用，不要依賴ini_set()或.user.ini、官方說明的限制：只擋特定路徑對應漏洞：CVE-2026-109619、設定：PHP 8.5 設
fatal_error_backtraces=0並重啟所有 worker、官方說明的限制：只擋已確認的 fatal backtrace 路徑
官方公告另列有容器或 cgroup 記憶體限制、在網頁伺服器或代理層限制請求大小等項目，完整清單與原文請看 php.net 公告。暫時設定不能取代升級，表上的設定要在升級完成後依應用需求還原或調整，改設定前先在測試環境確認不影響上傳功能。
常見問題
我的網站不是自己架的，需要處理嗎？
需要確認。託管在別人主機上的 PHP 網站，升級由主機商或維運廠商執行，你要做的是問清楚版本、升級日期與重啟日期，並留下回覆紀錄。
我們沒有 PHP 程式碼，還需要關心嗎？
盤點的問題是「有沒有任何系統在跑 PHP」，與自己有沒有寫 PHP 無關。WordPress、許多電商與表單系統、舊版官網、客戶端系統都可能跑 PHP。盤點時把外包網站、行銷活動頁與舊站一起列入，沒有 PHP 的系統在清單上標「無」並寫下確認日期。
WAF 開了就夠了嗎？
不夠。Cloudflare 的公告說明攻擊者會改寫攻擊內容嘗試繞過規則；PHP 官方也寫明沒有完整的緩解方式，升級是唯一安全的選擇。WAF 適合當升級前後的一層補強。
參考資料
PHP 官方安全公告與發布公告，2026-10-21：https://www.php.net/archive/2026.php
PHP 支援版本表：https://www.php.net/supported-versions.php 、終止支援表：https://www.php.net/eol.php
GitHub 安全公告：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w 與 https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
CVE 記錄：CVE-2026-109618、CVE-2026-109619（cve.org、NVD）
Wiz Research，PHP2Shell，2026-10-21：https://www.wiz.io/blog/php2shell-php-rce
Calif，php2shell，2026-10-21：https://calif.io/php2shell/
Cloudflare，PHP 漏洞與 WAF 防護，2026-10-21：https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
CISA 已知遭利用漏洞目錄（2026-10-21 版）：https://www.cisa.gov/known-exploited-vulnerabilities-catalog
本文為資訊整理，不構成資安或法律意見。你的環境實際是否受影響、如何升級，請與你的維運團隊或資安顧問確認。
