PHP2Shell 怎麼處理？PHP 更新版本與應對順序

文章導讀

PHP2Shell 的嚴重性來自四個條件同時成立：不需要登入、可以遠端執行程式、影響範圍很廣、修補前就已經外洩。處理的順序是先更新到修補版本，無法立即更新就先隔離，接著確認有沒有被入侵。

PHP 8.2 到 8.5 有官方修補版本（8.2.35、8.3.36、8.4.27、8.5.12）；8.1 以下沒有官方釋出的新版本，要另外規劃。
漏洞在 PHP 本身，更新 WordPress 或外掛修不到它，要更新的是主機上的 PHP。
防火牆與暫停服務是爭取時間的做法；PHP 更新完成之前，風險都還在。

本文重點導覽

嚴重性來自四個條件同時成立
先對照版本：PHP 落在哪一格
再看網站型態：被入侵後先受影響的是什麼
處理順序：更新、隔離、檢查、復原
防火牆與暫停服務，能爭取多少時間
更新完成之後，還要確認的四件事
公司內部這幾天要確認的事
PHP 8.2 年底停止支援，下一步要先排

「我們的網站是 WordPress，這次要不要緊？」PHP2Shell 公開這兩天，這是最常被問到的問題。答案要看兩件事：網站跑在哪個 PHP 版本，以及網站上承載了什麼資料與流程。這篇依版本與網站型態整理 PHP2Shell 的風險判斷，以及更新、隔離、檢查與復原的處理順序。

資訊更新

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

嚴重性來自四個條件同時成立

PHP2Shell 的官方評分是 CVSS v4.0 9.2 分（滿分 10 分），美國國家漏洞資料庫（NVD）用 CVSS v3.1 評為 9.8 分。這次會這麼嚴重，是因為下面四個條件同時成立：

不需要登入
攻擊者不必有帳號密碼，對網站送出特製的請求就可能觸發。
可以遠端執行程式
得手之後，攻擊者能讓伺服器執行自己的程式，讀取資料、植入後門或改掉網頁。
影響範圍很廣
研究團隊指出，受影響的版本可以追溯到 PHP 5.4；網站有沒有上傳檔案的功能，都在範圍內。
修補前就已外洩
消息在官方發布修補之前流出，攻擊者和防守的一方幾乎同時起跑。

「遠端執行程式」的意思，是攻擊者不用碰到你們的電腦或網站後台，就能讓主機照他的指令做事。這類漏洞一旦出現可用的攻擊程式，掃描通常是自動化、整個網段一起掃，不會挑網站的大小或產業。

先對照版本：PHP 落在哪一格

第一個判斷是版本。PHP 的版本由主機環境決定，在網站後台更新 WordPress 或外掛，不會改到它。

PHP 版本	官方支援狀態	這次的修補	代表的意思
8.5、8.4	積極支援中	8.5.12、8.4.27	更新到修補版本
8.3	只修安全問題，至 2027 年 12 月 31 日	8.3.36	更新到修補版本，明年底前規劃升級
8.2	只修安全問題，至 2026 年 12 月 31 日	8.2.35	更新只是第一步，年底前要再升級
8.1、8.0、7.4	已停止支援（EOL）	官方沒有新版本，只提供原始碼層級的修補	先確認主機上的 PHP 從哪裡來，並排定升級
7.3 以下、5.x	停止支援多年	官方沒有修補	先隔離，盡快規劃升級、搬家或重建

支援期限依 PHP 官方公告整理。Ubuntu、Debian 等作業系統發行版，會把修補移植到自己內建的 PHP（backport），版本號不一定跟著改變，判斷時要以主機實際安裝的套件為準。

這裡有兩個常被混在一起的詞。「更新」是在同一個版本線裡換到修補版，例如從 8.3.35 換到 8.3.36，相容風險通常不大。「升級」是跨版本，例如從 7.4 升到 8.3，網站的程式與模組都要先測過。8.1 以下的網站，這次面對的是後者。

網站跑哪個 PHP 版本，是主機環境的設定，負責維護的團隊能直接確認（內部人力或委外維護都算）。同一台主機也可能同時裝著好幾個 PHP 版本，分別給不同的網站使用，盤點時要一個一個對。

紙藝階梯的每一階代表一個 PHP 版本，上層四階完整，下層三階出現裂痕並被圍欄隔開 — 8.2 以上可以直接換到修補版；8.1 以下拿不到官方新版本，要先隔離再規劃升級。

再看網站型態：被入侵後先受影響的是什麼

同樣的漏洞，對不同網站的影響不一樣。處理的急迫度，要看網站上有什麼。

網站型態	被入侵後先受影響的	處理時要特別注意
形象官網	頁面被改、被植入惡意連結或轉址，搜尋排名與品牌信任受損	頁面與搜尋結果有沒有出現陌生內容
電商購物網站	訂單、會員個資與付款流程	金流串接的金鑰，以及個資外洩時的通知責任
會員、課程或報名系統	會員帳號、課程內容與報名資料	登入憑證與會員密碼的安全
內部網頁系統	訂單、庫存、ERP 等營運資料，也可能被當成進入公司網路的跳板	這類系統常不在網站清單裡，最容易被漏掉
設備或套裝軟體	路由器、網路儲存設備、設備管理頁面	要看原廠有沒有發布更新

盤點時最容易漏掉的，是不叫「網站」的網站。訂單後台、報名系統、設備的管理頁面，只要是網頁介面，背後都可能是 PHP。網站被入侵通常是哪一層出了問題，一個網站是由哪些部分組成的那篇有拆解。

處理順序：更新、隔離、檢查、復原

處理可以排成四步。每一步的技術做法，由維護團隊依版本與網站型態安排；你們公司內部負責營運面的決定，例如能不能暫停服務、怎麼向客戶說明。

更新到修補版本

8.2 以上換到修補版。先在測試環境確認關鍵流程，留好退回點，再更新正式站；更新後確認網站實際使用的 PHP 已經換成新版本。
無法立即更新，先隔離

8.1 以下或需要時間測試的系統，先縮小對外入口、加上防火牆的虛擬修補，必要時暫停對外服務。
檢查有沒有被入侵

漏洞在修補前就已外洩，更新之後仍要檢查：檔案有沒有被新增或修改、有沒有陌生的帳號與排程、主機有沒有異常的對外連線。
發現異常，進入復原

從確認乾淨的備份還原，更換網站、資料庫與串接服務的密碼與金鑰，並評估是否涉及個資外洩的通知。

四塊紙藝標示牌依序排列，分別是更新用的扳手、隔離用的圍欄、檢查用的放大鏡與復原用的備份盒 — 更新、隔離、檢查、復原四步，依網站的版本與型態決定先後。

四個步驟不一定要等前一步完成才開始下一步。同時有很多系統要處理時，先處理對外開放、涉及交易與個資的系統，形象官網與內部測試環境排在後面。個資外洩的情況，依個人資料保護法，要查明後以適當方式通知當事人。

防火牆與暫停服務，能爭取多少時間

網站防火牆的虛擬修補，能在請求抵達主機之前擋下已知的攻擊手法，Cloudflare 在修補公開之前就替客戶部署了規則。它能爭取時間，但只擋得住已知的模式；PHP 官方的說法是：「沒有完整的緩解方式，更新是唯一安全的選擇。」

常見誤解

有防火牆，就可以晚點更新

防火牆擋的是已知的攻擊手法，手法一變就可能被繞過；看到防火牆擋下攻擊，也不代表沒有漏網的請求。

實際情況

防火牆和更新要一起做

防火牆替更新爭取準備與測試的時間，PHP 換到修補版本之後，風險才真正解除。

暫停服務是另一種爭取時間的方式。歐洲多國政府網站、維基媒體基金會的部分服務與一些主機商，選擇在修補前先下線。英國國家網路安全中心（NCSC）與歐盟資安應變中心（CERT-EU）都建議，無法更新、也來不及套用暫時措施的系統，考慮先下線或與公開網路隔離。台灣資安署的新聞稿則呼籲儘速盤點與修補，沒有要求下線。

要注意的是，網站系統內建的「維護模式」擋不住這個漏洞。資安業者 Sansec 指出，PHP 在網站程式判斷要不要顯示維護頁之前，就已經處理了請求。真的要暫停服務，得在主機或網站防火牆的層級處理。

要不要暫停服務，是營運面的決定，由你們公司內部依兩件事判斷：網站停下來的影響有多大，以及多快能完成更新。停機的影響怎麼估，可以參考網站掛掉一天的損失估算。技術面的風險與替代做法，例如只關閉部分功能，或在主機層級改放維護頁面，由維護團隊提供判斷。

更新完成之後，還要確認的四件事

更新完成，代表之後利用這個漏洞的攻擊打不進來；修補前的空窗期有沒有被入侵，要另外確認。資安署的新聞稿也建議，更新後檢視系統日誌與異常存取紀錄。維護團隊在更新之後，會確認這四件事：

網站實際執行的 PHP 已換成修補版：只看指令列顯示的版本不夠，要從網站實際的執行環境確認。
主機上每一套 PHP 都處理到了：主機控制台常同時裝著好幾個版本，給不同的網站使用。
修補前後的紀錄都檢查過：檔案異動、陌生帳號、排程與對外連線沒有異常。
必要的密碼與金鑰已更換：特別是存在主機上的資料庫密碼與串接金鑰。

這是我們檢查主機時很常看到的情況：系統套件已經更新，網站背後的 PHP 服務卻還沒重新啟動，實際在跑的仍是舊版本。所以確認版本要從網站實際的執行環境看，指令列上的版本號只能當參考。

不要自行下載檢測工具

事件公開後，網路上出現大量號稱能一鍵檢測或修補的工具與攻擊程式，其中有些來源不明，甚至夾帶惡意程式。檢測交給維護團隊用官方或可信的方式進行，不要自行下載執行。

公司內部這幾天要確認的事

技術處理交給維護團隊，你們公司內部要準備的是營運面的資訊。下面幾項，都是你們公司內部要確認的事：

官網以外，公司還有哪些網頁介面的系統（訂單後台、報名系統、設備管理頁面），內部有一份清單。
每一套系統由誰負責維護（內部人力或委外維護都算），內部知道發生狀況時該通知誰。
網站如果需要暫停服務，內部由誰決定，對客戶的說明由誰發出。
客服與業務知道客戶問起這件事時，怎麼回應。
近期的活動或結帳高峰，內部已經整理成要避開的時段。

這些問題沒有技術門檻，卻常是事件當下最花時間的部分。名單、聯絡人和決策流程平常先整理好，狀況發生時才不會卡在「該問誰」。

PHP 8.2 年底停止支援，下一步要先排

這次更新到 8.2.35 的網站，還有一個時間點要注意：PHP 8.2 的安全支援在 2026 年 12 月 31 日結束。之後再出現漏洞，8.2 就和這次的 8.1 一樣，拿不到官方的修補版本。

紙藝桌曆翻到最後一頁，旁邊的沙漏快要流完，一旁的階梯通往放著新伺服器的平台 — 8.2 的安全支援只到 2026 年底，這次的更新之後，升級要接著排。

所以這次的更新，對很多網站只是第一步。8.2 的網站要在年底前升級到 8.3 以上。8.1 以下的網站，則要評估原地升級、搬到新環境或重建，三條路怎麼判斷，可以參考舊系統卡在舊版 PHP 時的升級、搬家與重建。跨版本升級前要測哪些地方，網站更新為什麼會壞那篇有完整說明。

我們怎麼處理 PHP 的緊急更新

代管期間，主機與 PHP 執行環境的更新由我們統一處理。遇到 PHP2Shell 這類緊急更新，參考的做法是先盤點：每台主機上跑著哪些 PHP 版本、分別服務哪些網站，再依版本與網站型態排出順序。

接著，每個網站先在測試環境確認關鍵流程，留好退回點，避開營運高峰再更新正式站。更新後，從網站實際的執行環境確認版本，並檢查修補前後的紀錄。8.1 以下的系統，先安排隔離與防護，再和你們討論升級、搬家或重建的路線。

這類緊急更新，和網站改版是兩件事。改版與內容更新由你們依檔期提出；PHP 與主機的版本更新、資安監看與備份驗證，不論這個月有沒有改東西，都持續在跑。

Consultation

把系統現況告訴我們

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

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

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

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

常見問題

更新 WordPress 或外掛，能修好 PHP2Shell 嗎？

要更新的是主機上的 PHP，WordPress 與外掛的更新改不到它。PHP2Shell 的漏洞在 PHP 這一層，WordPress 是跑在 PHP 上的程式；後台顯示一切都是最新版，PHP 仍可能停在有漏洞的版本。PHP 的版本由主機環境決定，要由負責主機的維護團隊確認與更新。

用虛擬主機的網站，主機商會自動更新 PHP 嗎？

要看主機的管理方式。多數虛擬主機的 PHP 由主機商統一管理，常會跟著更新到修補版本，但網站另外選用的舊版 PHP，不一定在同一批處理範圍內。VPS 或雲端主機的 PHP 由負責這台主機的人更新，主機商通常不會代為處理。實際版本與修補狀態，要由維護團隊在主機上確認。

網站沒有上傳檔案的功能，也會受影響嗎？

會。研究人員指出，這個漏洞不需要網站有上傳表單，對 PHP 程式送出特定格式的請求就可能觸發。網站有沒有會員、表單或上傳功能，都不影響它是否在範圍內，判斷的依據是 PHP 的版本與修補狀態。

網路上流傳的 PHP2Shell 檢測工具，適合自己拿來檢查嗎？

不建議自行下載執行。事件公開後，網路上出現大量號稱能一鍵檢測或修補的工具與攻擊程式，其中有些來源不明，甚至夾帶惡意程式。檢測應該由維護團隊用官方或可信來源的方式進行，結果也要對照網站實際的執行環境判斷。

已經修補了，還需要更換網站的密碼嗎？

要看修補前有沒有被入侵的跡象。漏洞在官方修補前就已經外洩，那段期間如果出現異常，主機上的資料庫密碼與串接金鑰都可能已經外流，需要一併更換。沒有發現異常時，由維護團隊依系統對外暴露的時間與用途，判斷是否預防性更換，並持續監看；網站後台的登入帳號，也可以趁這次確認都啟用了雙重驗證。

PHP2Shell 有多嚴重？依 PHP 版本與網站型態判斷風險，排出處理順序