PHP2Shell 是什麼？PHP 漏洞的起源、時間軸與影響

文章導讀

PHP2Shell 是 2026 年 10 月公開的兩個 PHP 核心漏洞，編號 CVE-2026-109618 與 CVE-2026-109619，攻擊者不需要登入，就可能在伺服器上執行程式。PHP 官方在 10 月 21 日晚間（台灣時間）釋出修補版本，消息卻在前一天就已外洩。

漏洞由 AI 輔助的資安研究找到；從消息外洩到修補公開不到一天，防火牆業者在修補公開前就觀察到攻擊流量。
PHP 支撐約七成的網站；台灣有露出版本的 PHP 對外服務中，84% 停在拿不到官方修補版本的 8.1 以下。
歐洲多國政府網站、維基媒體的部分服務，以及日本的遊戲與電商先行下線；台灣資安署呼籲儘速盤點與修補。

本文重點導覽

PHP2Shell 是什麼：兩個漏洞，一個名字
PHP 在網站裡的位置：為什麼影響這麼廣
事件時間軸：從 2024 年的稽核到緊急修補
為什麼消息會在修補前外洩
AI 找到漏洞，也壓縮了應變時間
全球影響：哪些服務選擇先下線
台灣的情況：官方呼籲與在地數字
這次事件留給企業網站的三個提醒

讓全球網站維運人員在 10 月 21 日整晚待命的，是一組名叫 PHP2Shell 的漏洞。那天晚上九點半左右（台灣時間），PHP 官方提前釋出四個緊急修補版本。同一天，荷蘭、芬蘭、法國都有政府網站先後下線，日本的遊戲與電商也公告停機維護。這篇整理 PHP2Shell 是什麼、怎麼被發現、為什麼提前外洩，以及它對全球與台灣網站的影響。

資訊更新

最後更新：2026 年 10 月 22 日。本文依 PHP 官方公告、研究團隊說明、資安署新聞稿與各國資安機關資料整理；事件仍在發展，內容有更新時會在這裡註明日期。

PHP2Shell 是什麼：兩個漏洞，一個名字

PHP2Shell 是揭露這組漏洞的研究團隊取的名字，字面意思是「從 PHP 拿到 Shell」，也就是取得伺服器的指令控制權。它包含兩個漏洞：

編號	官方說明	白話意思
CVE-2026-109618	RCE via OOM corruption（記憶體用罄造成的狀態損壞）	請求因記憶體用完而中斷時，留下沒清乾淨的記憶體，可能被拿來執行程式
CVE-2026-109619	RCE via stale global state（殘留的全域狀態）	前一個請求留下的狀態沒有重置，被同一個工作程序的下一個請求誤用

兩個漏洞的官方評分都是 CVSS v4.0 9.2 分。部分資安業者的文章，把問題對應到兩個編號的方式和官方不同；本文以 PHP 官方的安全公告為準。

兩個漏洞的問題，都出在 PHP 處理請求「中途出事」時的收尾。最典型的情況，是記憶體用超過上限，PHP 中斷了請求，卻沒有把記憶體清乾淨。攻擊者如果能控制中斷的時機，再把特製的資料放進那塊記憶體，就有機會讓伺服器執行他指定的指令。

問題出在 PHP 本身。網站自己的程式寫得再乾淨，只要跑在受影響的 PHP 版本上，都在範圍內，而且觸發不需要登入。研究團隊已經在 WordPress、Drupal、Joomla 等常見系統上，示範了不需要帳號的遠端執行。

PHP 在網站裡的位置：為什麼影響這麼廣

PHP 是讓網站「動起來」的程式語言。你看到的頁面、送出的表單、購物車裡的訂單，背後都要有一套程式在主機上執行，PHP 是其中最普遍的一種。依 W3Techs 在 2026 年 10 月的統計，已知使用哪種伺服器端語言的網站中，69.3% 用的是 PHP。

紙藝網站模型分成三層：最上層是頁面，中間是內容管理系統，最底層是代表執行環境的深藍色地基，地基出現一道裂縫 — PHP 位在網站最底層，地基出了問題，上面的系統再新也一樣受影響。

WordPress、Drupal、Joomla 這些內容管理系統都跑在 PHP 上；很多電商系統、會員系統、主機控制台，還有設備的管理頁面也是。網站的各個組成怎麼分工，可以參考一個網站是由哪些部分組成的。

所以這次的漏洞和一般的外掛漏洞性質不同。外掛漏洞只影響裝了那個外掛的網站；PHP2Shell 在更底層，跑在受影響版本上的網站都在範圍內，更新 WordPress 或外掛也碰不到它。

「後台都顯示最新版了，為什麼還有漏洞？」這是事件發生後最常被問到的問題之一。答案就在這一層：你在後台看到的是 WordPress 與外掛的版本，PHP 的版本是主機環境的設定，不會顯示在一般的更新通知裡。

事件時間軸：從 2024 年的稽核到緊急修補

這組漏洞的根源存在很多年，真正被找出來，是在 2026 年夏天。下表整理主要的時間點，10 月的事件都以台灣時間標示：

時間	事件
2024 年	PHP 首次接受外部資安稽核，核心開發者發現記憶體用罄時的問題雛形，但當時沒有證實能被利用，也沒有修補
2026 年 8 月	資安公司 Calif 在 OpenAI 的「Patch the Planet」計畫中稽核 PHP，向官方回報漏洞；Wiz 的研究團隊也獨立發現，並在 WordPress、Drupal 上確認可以遠端執行
2026 年 9 月	PHP 官方確認漏洞，開始開發修補並協調發布時程
10 月 20 日深夜	兩個漏洞編號在論壇與社群流傳，附帶錯誤的評分與發布時間
10 月 21 日凌晨	資安公司 watchTowr 在 X 上確認漏洞為真；PHP 官方發出預告，把發布提前一天；Calif 誤發攻擊示範影片後刪除
10 月 21 日上午	Cloudflare 替所有客戶啟用防火牆防護，並表示在修補公開前就觀察到攻擊流量
10 月 21 日下午	Chainguard 搶先發布含修補的映像檔，比協調發布時間早了六個多小時
10 月 21 日晚間	PHP 官方釋出 8.5.12、8.4.27、8.3.36、8.2.35，公開安全公告
10 月 22 日	數位發展部資安署發布新聞稿，呼籲儘速完成修補

依 PHP 基金會、研究團隊與歐盟資安應變中心（CERT-EU）的公開說明整理。原訂的發布時間是 10 月 22 日晚間，因消息外洩提前一天。

修補公開的同時，PHP 官方也說明，8.1 以下的版本已經不再由 PHP 專案更新。考量漏洞的嚴重程度，官方替 7.4、8.0、8.1 提供了原始碼層級的修補，給需要自行編譯的單位使用；更早的版本則沒有官方修補。

為什麼消息會在修補前外洩

資安漏洞通常走「協調揭露」：研究者先私下通知官方，雙方約定公開日。在那之前，修補只在少數必要的單位之間流通，讓多數網站在修補公開時就能更新。這次的協調，在最後兩天破了功。

先是漏洞編號和錯誤的評分在社群流傳，接著有資安公司公開確認漏洞為真，揭露者也誤發了攻擊示範影片，PHP 官方只好把發布提前一天。發布當天，又有業者搶先發布含修補的版本，PHP 基金會在說明中直接點名這件事。修補提前流出，等於讓攻擊者有機會先比對出修補改了哪裡。

PHP 基金會也坦承，問題在 2024 年的稽核就露出端倪，拖到現在，是「安全團隊的決策流程與資源不足造成的結構性失敗」。全球大量網站依賴的開源專案，維護人力其實相當有限，這也是這次國外社群討論最多的話題之一。

AI 找到漏洞，也壓縮了應變時間

這次的漏洞，是 AI 輔助的資安研究找到的。Calif 參與 OpenAI 的「Patch the Planet」計畫稽核 PHP，Wiz 則用自家平台搭配 Gemini 與 GPT 的模型。Wiz 在技術文章裡形容，一位研究員一週完成的工作，過去需要頂尖團隊花上好幾個月。

紙藝放大鏡停在一張程式碼紙卷上，旁邊有一枚晶片，沙漏上半部幾乎已經流空 — AI 讓找漏洞的速度變快，也讓修補公開到出現攻擊的時間變短。

AI 同樣加快了攻擊的速度。修補一公開，攻擊者也能用工具比對新舊版本的差異，反推出攻擊方法。資安業者 Sansec 在修補公開後就預期大規模攻擊即將出現；2024 年的 PHP 漏洞 CVE-2024-4577，公開後大約一天就出現大量攻擊嘗試。

對企業網站來說，這代表從漏洞公開到被大量掃描的時間，會愈來愈短。網站有沒有人持續盯著更新，結果的差距會比以前更明顯。

全球影響：哪些服務選擇先下線

PHP2Shell 公開前後，不少組織在修補完成前選擇先下線，寧可暫停服務，也不冒被入侵的風險。

政府與公共服務
荷蘭國家資安中心與眾議院網站、芬蘭政府的對外網路服務、法國內政部網站，以及丹麥的全國學校通訊平台，都曾預防性下線。
知識平台與網路社群
維基媒體基金會暫停了部分支援服務直到修補完成，4chan 等論壇也一度下線。
日本的遊戲與電商
《賽馬娘》《碧藍幻想》等遊戲與多個電商網站公告停機維護，日本的資安主管機關也呼籲立即更新。

各國資安機關的建議方向一致：盡快更新；做不到時，考慮把系統先與公開網路隔離，或暫時下線。英國國家網路安全中心另外提醒，處理時要檢查系統有沒有已經被植入後門。

下線也有代價。服務中斷的損失、客戶的疑慮，都要和被入侵的風險放在一起衡量。網站停機一天的損失怎麼估，可以參考網站掛掉一天，公司的損失怎麼估。

台灣的情況：官方呼籲與在地數字

數位發展部資安署在 10 月 22 日發布新聞稿，呼籲使用 PHP 的機關、學校與企業儘速確認版本並完成修補，更新後檢視系統日誌與異常存取紀錄。截至本文整理時，還沒有看到台灣的政府或大型服務因此停機的公告。

台灣網站對 PHP 的依賴程度，和全球相當；更值得注意的是版本：

67.9%.tw 網站使用 PHP 的比例（W3Techs，2026 年 10 月）
55.5%.tw 網站使用 WordPress 的比例（同上，以已知內容管理系統為母數）
84%台灣有露出版本的 PHP 對外服務中，停在 8.1 以下的比例（Mallory，2026 年 10 月 21 日）

最後一個數字來自資安業者 Mallory 在修補公開當天的統計：台灣有露出 PHP 版本的 23,977 個對外服務中，20,042 個停在 8.1 以下，也就是這次拿不到官方修補版本的範圍。

三個數字的母數不同，不能直接相乘：W3Techs 依網域統計網站，Mallory 依主機的 IP 所在地，統計的是對外服務。兩個來源指向同一件事：台灣有相當多網站跑在 PHP 上，其中不少停在已經停止支援的版本。

這次事件留給企業網站的三個提醒

如果你也是第一次聽到網站背後有 PHP 這一層，這很正常。很多公司第一次注意到網站的 PHP 版本，就是在這類事件之後。從這次事件，可以整理出三個提醒：

留給修補的時間變短了
從漏洞公開到被大量掃描，時間以小時計算。網站的更新要有人持續盯著，等到想起來才處理，往往已經太晚。
停止支援的版本會被拋在後面
這次 8.1 以下拿不到官方的修補版本。PHP 8.2 的安全支援也只到 2026 年底，版本規劃要提早排。
看不見的系統最容易漏掉
訂單後台、報名系統、設備的管理頁面，只要是網頁介面，背後都可能是 PHP，盤點要涵蓋官網以外的系統。

三個紙藝物件並排：一個快流完的沙漏、一本翻到最後一頁的桌曆，以及一盞照亮角落小主機的檯燈 — 修補時間、版本期限、看不見的系統，是這次事件留給企業網站的三個提醒。

各個版本該怎麼處理、處理的先後順序，在PHP2Shell 有多嚴重有完整整理。系統卡在舊版、沒辦法直接更新時，可以參考升級、搬家與重建怎麼選。

我們怎麼看待這次的 PHP2Shell 事件

這類事件剛發生的前兩天，資訊一天會變好幾次，評分、受影響的版本、有沒有被利用，各方說法都不一樣。參考的做法是以 PHP 官方的安全公告為準，再對照各國資安機關的建議。研究團隊與資安業者的文章當作補充，社群流傳的評分與攻擊程式，不直接拿來當判斷依據。

這篇整理的是事件的來龍去脈。實際處理時，代管期間的主機與 PHP 更新由我們統一安排；你們公司內部要準備的，是官網以外還有哪些系統，以及發生狀況時由誰決定、由誰對外說明。

網站內容與系統維護，走的是兩個時間表。網站改版與內容更新由你們依檔期提出；系統更新與資安監看，則不論這個月有沒有改東西，都持續在跑。

Consultation

把系統現況告訴我們

網站或系統卡在舊版 PHP，需要更新、搬家或重建時，填寫這份諮詢表單。
我們會依網站現況與執行環境，以 Email 回覆初步判斷。

約 2 分鐘完成
共 4 個步驟
以 Email 回覆

由於近期諮詢量較多，回覆需要一些時間，請耐心等候；我們會依緊急程度安排處理順序。

這份表單不需要填寫任何帳號或密碼，也請不要提供。填寫的內容只用於這次諮詢。

常見問題

PHP2Shell 和 2024 年的 PHP 漏洞 CVE-2024-4577 是同一個嗎？

是兩個不同的事件。CVE-2024-4577 在 2024 年 6 月公開，影響的是在 Windows 上以 CGI 模式執行的 PHP，由台灣的 DEVCORE 研究團隊發現。PHP2Shell 是 2026 年 10 月公開的兩個核心漏洞，問題在 PHP 引擎本身，受影響的版本可以追溯到 PHP 5.4。兩者的處理方式都是更新 PHP。