top of page

PHP2Shell 漏洞怎麼處理？台灣企業 PHP 網站的 5 步驟修補與 WAF 防護指南

Miles Ma
5天前
讀畢需時 6 分鐘

如果你的官網、電商、會員系統或內部後台是用 PHP 開發（包含 WordPress、Laravel 等常見架構），這週最需要排進待辦的一件事，就是確認伺服器上的 PHP 版本。PHP 官方在 2026 年 10 月 21 日發布安全公告，修正兩個被稱為「PHP2Shell」的重大漏洞，未經驗證的網路請求就可能觸發遠端程式碼執行。AWS 也發布安全公告，並表示偵測到在修補釋出前就已出現利用嘗試。


這篇文章不重複新聞細節，而是從企業 IT 與決策者角度整理：哪些環境受影響、該升到哪個版本、暫時無法升級時能做什麼，以及修補期間如何用 WAF 爭取時間。



PHP2Shell 是什麼？先看已確認的事實


以下內容整理自 PHP 官方公告、AWS 安全公告與資安廠商報告（查核日期：2026-10-27）。


  • 兩個漏洞： CVE-2026-109618（記憶體不足處理時，請求資料只完成部分初始化，清理流程誤用而造成記憶體破壞）與 CVE-2026-109619（請求結束後，殘留的內部狀態被同一個 worker 的下一個請求誤用）。

  • 影響： 兩者都可能導致未經驗證的遠端程式碼執行（RCE）。Fortinet 報告引用的 CVSS 4.0 分數為 9.2。

  • 受影響的執行方式： PHP 官方指出，所有處理網頁請求的 PHP 安裝都在風險範圍內，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed，其中 mod_php 風險最高，因為攻擊可能在任何應用程式碼執行前就被觸發。

  • 已修補版本： PHP 8.5.12、8.4.27、8.3.36、8.2.35。

  • 舊版本： PHP 8.1 以前已不再由 PHP 官方提供更新。官方為 7.4、8.0、8.1 提供了最小化的原始碼修補，但 AWS 公告也提醒，5.4–8.1 屬於終止支援版本，應盡快遷移到受支援的版本。

  • 利用狀況： AWS 威脅情報表示，最早的利用嘗試出現在 10 月 17 日，早於正式修補。也有資安業者觀察到的活動多為掃描與無效的 PoC。實際成功入侵的規模目前仍無公開定論。

  • 後續發展： PHP 基金會 10 月 23 日另行公告一個待修補的 RCE 漏洞 CVE-2026-115560，觸發條件少見，官方建議先將 session.upload_progress.enabled 設為 0，並會在下次例行版本中修正。



為什麼台灣企業要特別注意？


以下為 WeWinCloud 的分析與建議，非官方說法。


台灣許多中小企業的官網、活動頁與電商站採用 PHP 架構，而且常由外包廠商建置後就交由內部人員維護。我們在實務上常看到三種情況，會讓這類漏洞的風險被放大：


  1. 只更新 CMS，沒更新 PHP。 WordPress 或外掛顯示「已是最新版」，但底層 PHP 仍停留在舊版。這次的漏洞在 PHP 執行環境本身，更新 CMS 並不能修補。

  2. 主機沒有明確負責人。 網站放在雲端主機或虛擬主機上，帳號在行銷部門、維護在外包商，出事時沒有人能立刻判斷版本與修補方式。

  3. 長期停在終止支援版本。 系統上線多年仍在 PHP 7.x 或 8.0 / 8.1，升級牽涉程式相容性，一直被延後。


換句話說，這次事件真正考驗的不只是「會不會打補丁」，而是企業是否清楚自己有哪些對外服務、跑在什麼版本上，以及誰能在 24 小時內處理。



受影響範圍與處理方式對照


你的環境

狀態

建議處理方式

PHP 8.2 / 8.3 / 8.4 / 8.5

有官方修補

升級到 8.2.35、8.3.36、8.4.27 或 8.5.12，並重新啟動所有 PHP worker

PHP 7.4 / 8.0 / 8.1

官方已不提供版本更新

洽作業系統或 LTS 廠商取得 backport 修補，同時規劃升級到受支援版本

PHP 7.3 以前

終止支援

先套用臨時緩解並限制曝險，優先規劃遷移

AWS Elastic Beanstalk

AWS 已釋出新平台版本

開啟 Managed Platform Updates，或手動更新平台版本

Amazon Lightsail

新藍圖已提供

現有執行個體無法原地更新，需以新藍圖建立並遷移

Amazon Linux 自建主機

已提供更新套件

盡快套用套件更新並確認實際執行版本

Lambda 自訂 runtime / 容器映像

需自行更新

更新映像內的 PHP 版本並重新部署


表格依據 AWS 安全公告 2026-143-AWS 與 PHP 官方公告整理。其他雲端平台或虛擬主機商，請以各自公告為準。



企業 PHP 網站 5 步驟檢查清單


步驟 1：盤點所有對外的 PHP 服務


列出官網、電商、活動頁、會員系統、API 與內部後台，標示主機位置（自建、雲端主機、虛擬主機或託管平台）和負責人。容易被遺漏的是早期活動網站與測試環境。


步驟 2：確認「實際執行」的 PHP 版本


在主機上確認實際執行中的 PHP 版本，而不是只看套件管理員顯示的版本。部分 Linux 發行版會在不改版本號的情況下 backport 修補，需要查對廠商公告確認套件內容。


步驟 3：升級並重新啟動 worker


升級到官方修補版本後，要重新啟動或替換所有 PHP-FPM、Apache 等 worker，並再次確認運行中的服務已載入新版本。只安裝套件而沒有重啟，舊版本仍可能在記憶體中繼續執行。


步驟 4：暫時無法升級時，先套用臨時緩解


PHP 官方列出的臨時措施包括：關閉 session.upload_progress.enabled、在不需要大型上傳的服務降低 post_max_size，以及在 Web 伺服器或代理層限制請求大小與欄位數量。這些措施只能減少特定攻擊路徑，不能取代升級。


步驟 5：檢查是否已有入侵跡象


若主機在修補前長時間暴露，建議檢查異常程序、新增的檔案或排程、不明的對外連線，以及 Web 日誌中大量異常的 multipart POST 請求。安裝修補並不會移除已經進入系統的攻擊者。



修補期間，WAF 能做什麼、不能做什麼？


WAF（網站應用程式防火牆）可以在應用程式前面過濾可疑請求，是修補期間常用的過渡防護。AWS 表示，AWS WAF 的 PHP 受管理規則群組已更新以涵蓋這兩個 CVE，使用預設版本的客戶會自動套用，固定版本的客戶則需要手動更新到最新版本。其他 CDN 與 WAF 供應商也陸續釋出對應規則。


不過，WAF 有它的限制：


  • 它是降低風險，不是修補。 攻擊手法可能出現變形，規則不一定能涵蓋所有變體。

  • 只保護有經過 WAF 的流量。 若主機 IP 可以被直接連線，攻擊者仍可能繞過 WAF。建議同時限制來源，只允許 CDN 或負載平衡器連入。

  • 規則需要確認已啟用。 不少企業「有買 WAF」，但規則群組停在舊版本，或只開啟監控（Count）模式而沒有阻擋。


較實際的做法是「WAF 先擋、版本盡快升、日誌持續看」三件事同時進行。



常見問題


我們用的是 WordPress，更新到最新版就安全了嗎？


不一定。PHP2Shell 是 PHP 執行環境本身的漏洞，WordPress 與外掛的更新無法修補它。請確認主機上的 PHP 版本已升到官方修補版本。


網站放在虛擬主機，我們能做什麼？


先向主機商確認 PHP 版本與修補時程，並查看控制台是否能切換到已修補的 PHP 版本。若主機商無法提供明確時程，就應評估遷移到可自行控管版本的環境。


已經有防毒軟體或 EDR，還需要處理嗎？


需要。EDR 能協助偵測主機上的異常行為，但漏洞本身仍需透過升級修補。兩者是互補關係，不能互相取代。



結語：把這次事件變成一次盤點


PHP2Shell 不會是最後一個影響廣泛的 Web 執行環境漏洞。比起每次事件發生才緊急應變，更值得做的是建立一份對外服務清單、明確的版本更新責任，以及修補期間的 WAF 與監控機制。


WeWinCloud 提供 WAF 網站防火牆、DDoS 防護、EDR / MDR 端點防護與資安顧問、弱點評估等資安防護服務。



需要協助盤點 PHP 網站的版本與曝險、設定 AWS WAF 規則，或規劃舊系統的升級與遷移？👉 與我們聯繫，由專人協助評估。



延伸閱讀



參考資料

留言

bottom of page