2026 PHP 重大資安漏洞爆發！影響版本、修補教學與企業網站應變指南

一、PHP2Shell 是什麼？為什麼這次漏洞這麼嚴重？

PHP 廣泛應用於企業官網、電商平台、會員系統及後台管理工具。本次兩項漏洞位於 PHP 執行環境，而非單一網站外掛，部分攻擊路徑可能在應用程式進行登入驗證之前就被觸發。

:code FAQ

CVE-2026-109618：記憶體不足時的異常處理

當 PHP 處理網路請求遭遇記憶體不足（Out of Memory，OOM）時，部分內部資料清理可能不安全，形成記憶體毀損風險。攻擊者在特定條件下可能利用異常行為執行惡意程式碼。

CVE-2026-109619：釋放後使用（Use-after-free）

這類問題是指程式錯誤引用已釋放的記憶體。本次漏洞涉及 PHP 內部請求與狀態管理，可能導致程式崩潰，並在特定條件下造成遠端程式碼執行。

沒有登入後台、沒有上傳功能，還會受影響嗎？

仍有可能。網站沒有購物車或公開上傳功能，不能直接認定底層 PHP 安全。若攻擊成功，可能發生網站被竄改、伺服器服務中斷、設定檔或憑證遭存取，以及會員、訂單、詢價資料暴露等後果。但存在漏洞不等於已遭入侵，資料外洩也必須依證據判斷。

技術來源：PHP 官方、CERT-EU

二、國內外如何因應？日本政府曾暫停部分網站服務

日本：預防性停站與修補後恢復

日本部分政府服務因應 PHP 漏洞採取預防性暫停措施。例如日本財務省公告於完成必要安全措施與檢查後，逐步恢復部分網站內容。此類停站不代表網站已確定遭駭，而是風險尚未排除前的一種保護措施。

歐盟：優先修補，不能修補時考慮隔離

CERT-EU 建議儘速修補 PHP 環境；若無法立即更新，應評估暫時隔離對外應用服務，以降低未經修補期間的暴露風險。

台灣：盤點版本、更新並檢查日誌

台灣資通安全署提醒企業與機關盤點使用 PHP 的系統，依官方安全公告更新，並持續檢查異常登入、主機日誌與可疑存取紀錄。

原始資料：日本財務省、CERT-EU、台灣資安署

三、PHP 重大漏洞怎麼修補？不同版本的處理方式

優先採用官方安全版本；若網站過舊、跨版本升級會造成相容性問題，可確認主機商是否提供 Backport（回移修補）。回移修補是針對特定漏洞將修正套用到舊版套件，並不代表舊版本已重新獲得全面安全支援。

1. PHP 8.2～8.5：官方最低修補版本

2.Plesk：7.4、8.0、8.1 也可能有修補建置

Plesk 官方對 Linux 平台列出 PHP 7.4.33、8.0.30、8.1.34 的特定修補建置。其修補判斷需核對供應商套件與 2026 年 10 月 21 日建置資訊，不能只靠版本號。Plesk Windows 環境須另行核對官方文件。

3.cPanel EasyApache 4：核對套件修訂號

cPanel 已針對多個 PHP 分支提供 EasyApache 4 修補套件。使用 PHP 7.4.33 的網站，應由主機管理者確認是否安裝對應的 7.4.33-19 或後續已修補套件，而非只查看前台 PHP 版本。

4.CloudLinux：極舊 PHP 也可能取得延伸修補

部分 CloudLinux EasyApache 4（ea-php）套件提供 PHP 5.6～8.x 的本次漏洞修補，但不代表所有 CloudLinux 系統或 alt-php 都採用相同修訂號，部分延伸支援服務也可能有額外費用。

注意：表列為特定套件修訂資訊，實際完整套件版號與是否涵蓋兩項 CVE，仍應以 CloudLinux 官方當期公告及伺服器實際安裝資料為準。

原廠公告：Plesk、cPanel、CloudLinux

四、如何確認 PHP 已真正完成修補？

這次最容易誤判的狀況是：PHP 版本號一樣，實際安全修補狀態卻不一樣。尤其 Plesk 7.4.33 等舊版回移修補，可能要看建置日期、套件來源及變更紀錄才能確定。

方式一：查看 Plesk 的 PHP 設定

進入網域的「PHP 設定（PHP Settings）」查看已啟用的 PHP 版本與 FPM 等處理器。若使用舊版回移修補，還須由主機管理者進一步核對原廠套件與建置資訊。

方式二：在受限制的環境檢查 phpinfo()

工程師可利用 PHP 的資訊函式查看執行環境、PHP Version、Build Date 與 Server API：

例如實際查核畫面可見「PHP Version 7.4.33」與「Build Date：Oct 21 2026 13:44:08」。這可作為 Plesk Linux 特定修補建置的線索，但不能只憑 Build Date 斷言兩項 CVE 已修復，仍須核對套件來源與修補紀錄。

資安提醒：phpinfo() 可能揭露內部路徑與伺服器組態，應限制存取，查核後立刻刪除，勿長期公開。

方式三：主機工程師查核套件及網站實際使用的 PHP

例如 cPanel EasyApache RPM 環境，可由具備權限的管理員查看相關套件與變更紀錄：

這些指令僅適用於相應 RPM 套件環境，其他平台需改用原廠指定的查核方式。此外，php -v 顯示的是 CLI 版本，不一定等於網站使用的 PHP-FPM 或 Apache 模組。

建議驗證順序：實際 PHP 執行環境 → 套件來源及修訂版 → CVE 修補證據 → 服務重新載入 → 前後台功能測試 → 異常存取查核。

五、購物車、企業官網與老舊系統，各自怎麼應變？

購物車／會員系統：優先保護交易與個資

除 PHP 修補外，應確認會員資料、訂單、收件資訊、後台管理操作、金流通知及 API 介接是否正常；有疑似入侵跡象時，檢查大量資料查詢、異常匯出與未授權帳號。若暫時無法控制風險，應評估暫停接單或整體動態服務。只把結帳按鈕隱藏，不等於漏洞已解除。

企業形象網站：詢價與附件仍可能涉及敏感資訊

即使沒有會員或購物車，網站仍可能儲存詢價內容、聯絡資料、履歷、附件或主機設定檔，因此仍須修補 PHP 並檢查異常操作。

舊版內部系統：先限制公開暴露

若因相容性或供應商套件尚未到位而無法立即更新，可評估僅允許內網、VPN 或授權連線存取，並同步規劃正式修補或環境遷移。

無法立即修補：WAF、隔離或停機公告

Cloudflare WAF 可協助降低部分惡意流量，但不能取代 PHP 核心修補。對高風險且無法修補的對外服務，必要時應改由安全的靜態頁面顯示維護公告，並確實停止或隔離原本有漏洞的 PHP 路徑。

維護頁實作可視情況採用 HTTP 503 與 Retry-After；應由工程師確認停機方式不再暴露原 PHP 服務。

參考：Cloudflare WAF 說明、CERT-EU 緊急處置建議

六、PHP 更新完成，還需要檢查什麼？

修補能降低後續漏洞被利用的可能，但不能直接證明修補前沒有遭入侵。建議由技術團隊依風險檢查：

• Web Server Log、PHP Error Log、可疑 HTTP 請求與異常程序。
• 網站檔案是否遭竄改、出現不明程式或帳號。
• 會員資料、後台敏感資訊、訂單或資料庫是否遭異常存取。
• 資料庫密碼、API 金鑰等憑證是否可能暴露，必要時進行輪替。
• 前台、後台、上傳、付款及第三方介接功能是否正常。

若發現疑似入侵或外洩跡象，應先保全證據，進行隔離與影響範圍調查，再評估必要的法規通報與客戶通知，避免只更新版本便宣稱事件已結束。

七、愛貝斯如何應對此次 PHP 資安危機？

本次事件對網站維運公司的考驗，不只是單一漏洞更新，而是能否迅速盤點不同客戶的 PHP 版本、主機供應商與管理權限，並據此判斷優先處理順序。

第一時間連夜追蹤

依愛貝斯此次內部應變紀錄，工程團隊連夜追蹤國內外主機商的安全更新狀態，持續確認哪些環境已有套件、哪些需要等待供應商處理。

依管理權限分流修補

對具備管理權限、可自行處理的主機，優先執行修補；對由第三方主機商管理的環境，持續聯繫協調、確認更新進度。實際進度因各客戶的主機與版本而異，不能一概視為全數完成。

無法立即更新的內部系統，先限制外網存取

部分內部管理系統須等待原廠更新套件，工程團隊先限制其外部網路存取，以降低等待修補期間的暴露風險。

網站上線不是終點。持續管理版本、追蹤弱點公告、確認主機修補與監控異常，才是企業網站長期維運的重要工作。

八、PHP 資安漏洞常見問題 FAQ

Q1：PHP 7.4 已停止官方支援，還能修補這次漏洞嗎？

 雖然部分主機平台可透過安全補丁暫時修補本次漏洞，但這類方式終究只是權宜之計，無法根本解決舊版系統長期累積的資安風險與相容性問題。建議儘早規劃網站改版，升級至受官方支援的 PHP 版本，降低長期資安與維護風險。

Q2：PHP 5.6 網站只能重新製作嗎？

強烈建議儘早規劃網站改版升級。對於 PHP 5.6 等過於老舊的網站，即使能透過延伸安全支援或補丁暫時降低風險，也只是治標不治本。隨著系統停止官方維護，未來可能面臨更多資安漏洞、功能不相容及維護困難等問題。與其持續依賴臨時補救措施，不如趁此機會重新檢視網站架構，規劃全面改版，才能真正提升網站的安全性、穩定性與長期維運保障。

Q3：Plesk 顯示 PHP 7.4.33，代表已修補嗎？

不一定，不能單看版本號。須依供應商公告確認建置日期、套件來源及修補紀錄，並確認網站實際執行該套件。即使主機商已針對舊版 PHP 提供安全補丁，也必須進一步確認修補是否真正生效。

綜合Q1~Q3的問題，安全補丁只是暫時解方，網站改版才是長久之計。這類補救措施只能暫時降低特定漏洞風險，無法解決舊版系統長期缺乏維護的問題。與其持續依賴補丁延續網站壽命，不如儘早規劃網站改版，升級至受官方支援的 PHP 版本，才能有效降低未來資安風險與維護成本，避免未來再次面臨相同的資安困境。

Q4：透過 phpinfo() 就能確定已修補嗎？

phpinfo() 只能提供版本、Build Date 及環境線索，還要核對原廠套件與 CVE 修補資訊。資訊頁不可長期對外公開。

Q5：使用 Cloudflare，就不必更新 PHP 嗎？

不行。Cloudflare 提供 CDN（內容傳遞網路） 與 WAF（網站應用程式防火牆），雖然 WAF 能協助阻擋部分惡意攻擊，但無法修復 PHP 本身的漏洞。企業仍須完成 PHP 安全更新，才能從根本降低網站資安風險。。

Q6：網站更新後，就代表沒有資料外洩嗎？

不代表。是否遭入侵或資料外洩，需要依系統日誌、異常操作與調查證據判斷。

結語：資安危機無法完全預測，但可以提前準備

PHP2Shell 提醒企業，網站能正常開啟，不代表底層執行環境毫無風險。對舊版 PHP 而言，並非所有情況都只能立即改版；但無論選擇官方修補、回移補丁或暫時隔離，都必須由工程師確認實際風險與驗證結果。

真正值得信賴的網站維運，不只是網站故障後才處理，而是在資安事件發生時，能主動盤點、快速判斷、適切修補並持續追蹤。

官方參考資料

1. PHP 官方安全公告：php.net
2. 台灣資通安全署：moda.gov.tw
3. 歐盟 CERT-EU 安全通報：cert.europa.eu
4. 日本財務省網站維護公告：mof.go.jp
5. Plesk 官方修補說明：support.plesk.com
6. cPanel EasyApache 4：support.cpanel.net
7. CloudLinux 修補與驗證：cloudlinux.zendesk.com
8. Cloudflare WAF 防護：blog.cloudflare.com

本文資料整理日期：2026 年 10 月 23 日。修補套件與主機商支援範圍可能持續變動，實際操作請依原廠最新公告及主機管理工程師評估執行。