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

文章導讀

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

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

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 版本，分別給不同的網站使用，盤點時要一個一個對。

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

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

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

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

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

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

• 更新到修補版本

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

• 無法立即更新，先隔離

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

• 檢查有沒有被入侵

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

• 發現異常，進入復原

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

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

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

網站防火牆的虛擬修補，能在請求抵達主機之前擋下已知的攻擊手法，Cloudflare 在修補公開之前就替客戶部署了規則。它能爭取時間，但只擋得住已知的模式；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 的網站要在年底前升級到 8.3 以上。8.1 以下的網站，則要評估原地升級、搬到新環境或重建，三條路怎麼判斷，可以參考舊系統卡在舊版 PHP 時的升級、搬家與重建。跨版本升級前要測哪些地方，網站更新為什麼會壞那篇有完整說明。

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

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

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

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

常見問題