PHP2Shell 漏洞修補指南：CVE-2026-109618／109619 與 Bitdefender 防護

10/23/2026

PHP2Shell 重大遠端程式碼執行漏洞：企業應變指南與 Bitdefender GravityZone 防護建議

2026 年 10 月，PHP 官方釋出兩項重大安全漏洞修補，漏洞編號為 CVE-2026-109618 與 CVE-2026-109619，兩者 CVSS v4.0 評分均為 9.2，並可能導致未經驗證的遠端程式碼執行（Remote Code Execution，RCE）。

Bitdefender 將這兩項漏洞合稱為 PHP2Shell，並指出所有提供 Web 請求處理的未修補 PHP 環境都應視為高風險，其中以 Apache 使用 mod_php 的環境最需要優先處理。Bitdefender 的技術分析也提醒，這次漏洞屬於 PHP 執行環境本身的問題，不需要攻擊者登入，也不一定需要利用 WordPress、Drupal、Joomla 或自製應用程式的漏洞。閱讀 Bitdefender 官方技術分析

一、PHP2Shell 為什麼需要立即處理？

PHP2Shell 不是一般網站應用程式漏洞，而是發生在 PHP Worker 處理請求時的記憶體安全問題。

兩項漏洞的特性如下：

CVE-2026-109618：與 PHP 記憶體不足（Out-of-Memory，OOM）處理流程中的記憶體損毀有關。
CVE-2026-109619：與請求之間殘留的全域狀態及釋放後使用（Use-After-Free）有關。
兩者都可能在未經身分驗證的情況下被遠端觸發。
在 Apache mod_php 環境中，攻擊可能發生在應用程式程式碼執行前。
攻擊者不一定需要利用 WordPress、Drupal、Joomla 或其他 CMS 的弱點。

因此，單純更新 WordPress、Laravel、外掛程式或網站原始碼，並不能修補 PHP2Shell。企業必須直接更新 PHP 執行環境，並確認 PHP-FPM、Apache 或容器中的實際版本已經替換完成。

PHP 官方建議更新至：

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

PHP 官方也提醒，PHP 8.1 及更舊版本已不再獲得 PHP 專案的正式安全更新。企業若仍使用舊版本，必須向作業系統供應商、Linux 發行版或主機代管商確認是否提供回溯修補；若沒有，升級至受支援分支才是較可靠的處理方式。PHP 官方安全公告

二、目前是否代表企業已經遭到入侵？

Bitdefender 官方技術分析指出，截至 2026 年 10 月 22 日發布該通告時，Bitdefender Telemetry 尚未觀察到 PHP2Shell 的實際利用活動，Bitdefender Labs 與 MDR 團隊也持續監控相關威脅。

不過，「目前尚未觀察到」不代表企業可以等待。

需要區分以下三種情況：

漏洞已被公開揭露：代表外界知道漏洞存在及其影響範圍。
概念驗證程式（PoC）已出現：降低攻擊者自行開發攻擊工具的門檻。
實際入侵活動：攻擊者已對真實目標發動攻擊並留下請求、程序、檔案或連線等證據。

PHP2Shell 已經完成公開揭露並釋出修補版本，研究人員也展示了可行的攻擊方式，因此企業不應以「尚未確認大規模攻擊」作為延後修補的理由。另一方面，企業也不應僅因為漏洞嚴重度高，就直接認定所有受影響主機都已遭到入侵。

正確做法應該是：

立即修補，並同步檢查修補前是否曾出現入侵跡象。

三、哪些 PHP 環境需要優先盤點？

企業不應只檢查主要網站，還應將下列環境納入盤點：

對外公開的正式網站
WordPress、Drupal、Joomla 等 CMS 主機
電商、會員、付款及客戶資料系統
Apache mod_php
PHP-FPM
PHP-CGI
FrankenPHP
LiteSpeed
雲端虛擬機
容器映像檔與 Kubernetes 工作負載
測試與開發環境
主機代管商提供的網站服務
內建 PHP 的網路設備、管理平台或第三方應用程式

Bitdefender 特別提醒，不能只依賴執行 php -v 的結果。php -v 通常反映的是命令列使用的 PHP binary，不一定等於 Web Server 實際載入的 PHP 版本。

企業應確認：

Web Server 實際使用的 Server API（SAPI）
Apache 是否載入 mod_php
PHP-FPM 實際執行的版本
容器使用的基礎映像檔版本
作業系統套件是否已套用回溯修補
PHP 是否為自行編譯或由第三方套件提供

如果使用 Linux 發行版的回溯修補，版本號可能不會明顯改變。因此，不能只看到版本號低於修補版本，就直接判定未修補；也不能只看到套件已更新，就忽略套件變更紀錄及供應商安全公告。

四、企業應依循的四階段應變流程

第一階段：建立 PHP 資產清單

企業首先要確認「哪些主機正在提供 PHP Web 服務」。

建議從以下資料來源交叉比對：

CMDB 與資產管理系統
Web Server 設定檔
PHP-FPM Service
Dockerfile 與容器基礎映像檔
雲端主機及負載平衡器
DNS、WAF 與反向代理紀錄
GravityZone 軟體盤點資料
外部攻擊面掃描結果

對外服務尤其需要優先處理，因為攻擊者不需要進入企業內部網路，就可能直接從網際網路發送請求。

第二階段：套用修補並驗證

請更新至 PHP 8.2.35、8.3.36、8.4.27 或 8.5.12 以上版本，並完成以下動作：

重新啟動 PHP-FPM Worker
重新啟動 Apache 或 LiteSpeed
重新部署更新後的容器映像檔
確認負載平衡器後方所有節點均已更新
確認備援站台及災難復原環境也已更新
重新執行版本及套件盤點
保存修補前後的變更紀錄

若只更新套件但未重新啟動執行中的 PHP Worker，舊程式碼仍可能持續留在記憶體中，導致系統沒有真正完成修補。

第三階段：無法立即更新時降低曝險

PHP 官方與 Bitdefender 均指出，這些設定只能降低部分攻擊路徑，不能視為完整替代方案。

在等待正式修補期間，可依環境評估下列措施：

停用 session.upload_progress.enabled
PHP 8.5 環境可評估停用 fatal_error_backtraces
PHP-FPM 可評估設定 pm.max_requests=1
透過 Web Server 或反向代理限制請求大小
使用 WAF 或反向代理封鎖異常請求
限制管理介面只能透過 VPN 或白名單連線
暫時將非必要對外服務下線
重新啟動所有 PHP Worker，使設定真正生效

對於 OOM 相關路徑，Bitdefender 建議搭配適當的應用程式請求大小限制、容器或 cgroup 資源界線。企業不應直接依賴作業系統的單一程序記憶體限制，因為錯誤的資源限制可能反而造成可被利用的記憶體配置失敗。

第四階段：修補後進行入侵調查

Bitdefender 建議將調查起始時間回溯至 2026 年 10 月 17 日，這是第三方研究資料所提及的最早攻擊嘗試日期；不過該資訊並非 Bitdefender 獨立確認的 PHP2Shell 成功入侵證據。

建議檢查下列跡象：

Proxy 或 WAF 紀錄中出現異常大型請求
PHP 出現 Unknown on line 0 的記憶體不足錯誤
Apache Log 出現 AH00052
Apache、httpd、PHP-FPM 或 php-cgi 啟動 Shell
Web Worker 建立反向連線
Upload、Cache、Temp 目錄出現新的 PHP 或 Script 檔案
網站根目錄出現不明檔案
主機向陌生 IP 或網域連線
出現不明帳號、排程、Cron 或服務
伺服器出現工具下載行為

需要注意的是，沒有錯誤紀錄並不能證明主機沒有遭到入侵。成功的攻擊可能不會造成 PHP Crash，也可能回傳正常的 HTTP 200 狀態。

如果確認主機遭入侵，除了清除惡意檔案之外，還應重新設定或撤換 PHP 程序可能讀取到的：

資料庫帳號密碼
API 金鑰
.env 或設定檔中的密碼
雲端存取金鑰
SSH 金鑰
第三方服務憑證
管理員登入資訊

五、Bitdefender GravityZone 如何協助企業？

PHP2Shell 的漏洞本身發生在 PHP Worker 內部的記憶體處理流程，因此端點防護產品的主要任務不是取代 PHP 修補，而是偵測攻擊者利用漏洞取得權限後的行為。

Bitdefender 官方分析指出，GravityZone 的防護重點包括：

啟動 Shell
建立反向 Shell
寫入 Web Shell
下載攻擊工具
權限提升
建立新帳號
修改排程
建立持久化機制

1. GravityZone EASM：先找出對外暴露的 PHP

External Attack Surface Management（EASM） 可從企業外部檢視公開資產，不需要在主機上安裝 Agent，適合用來找出企業可能遺漏的網際網路服務。

EASM 可協助企業了解：

哪些公開 IP 正在提供 Web 服務
哪些網站可能使用 PHP
對外服務的版本與曝險狀態
未納入內部資產清單的主機
第三方或雲端代管的公開服務

對於大型企業、併購後環境、分散式子公司及使用多家主機代管商的組織，EASM 可作為第一層外部資產盤點工具。

了解 Bitdefender External Attack Surface Management

2. GravityZone Risk Management：找出受管理端點的 PHP 風險

GravityZone Risk Management 主要針對已納管的端點與伺服器，盤點已安裝的 PHP 版本，並比對 NVD 及特定 Linux 發行版的安全公告。

它適合用來回答：

哪些受管理伺服器安裝了 PHP？
哪些主機可能受 CVE-2026-109618／109619 影響？
哪些系統仍使用舊版 PHP？
哪些主機缺少相關安全更新？
哪些漏洞應優先處理？

需要注意的是，Risk Management 的盤點結果仍應與 Web Server 實際執行版本交叉驗證，尤其是存在多個 PHP binary、自行編譯版本、容器化服務或代理轉發架構時。

了解 Bitdefender Risk Management

3. GravityZone Patch Management：將修補從盤點落實到部署

GravityZone Patch Management 可協助企業執行修補盤點、安裝及報告管理，支援的範圍取決於作業系統、套件來源與 Bitdefender 支援清單。

建議企業將 Patch Management 用於：

建立缺少修補程式的主機清單
找出具有 CVE 對應修補的系統
依伺服器重要性安排維護時段
批次推送受支援的套件更新
產出修補前後的報告
建立例外與未修補原因紀錄

不過，以下情況仍可能需要手動處理：

自行編譯的 PHP
未列入支援清單的第三方套件
容器映像檔內建的 PHP
由主機代管商管理的 PHP
使用特殊 Linux 發行版的環境
尚未由套件供應商提供修補的舊版本

容器環境必須重新建置並替換執行中的映像檔，不能只更新建置主機上的 PHP。

了解 Bitdefender Patch Management

4. GravityZone EDR：調查 PHP Worker 後續行為

GravityZone EDR 的價值在於提供端點程序活動與攻擊鏈可視性，協助資安團隊調查 PHP Worker 是否執行了不應該執行的動作。

Bitdefender 官方列出的相關偵測涵蓋：

Linux：

Web Service 啟動 Shell
PHP Reverse Shell
Web Server 可疑行為
Web Shell 寫入
可疑子程序建立

Windows：

PHP Web Shell
Web Shell 建立
Certutil 或 Curl 下載工具
PowerShell 下載
建立排程工作
建立新帳號或修改本機管理員群組

macOS：

Web Service 啟動 Shell
PHP 反向連線
Curl 下載
Cron 修改
隱藏檔案執行

需要特別說明的是，這些偵測主要針對「漏洞被利用後的行為」，不是保證能在 PHP 記憶體損毀發生的瞬間攔截漏洞本身。不同 SAPI、作業系統及 PHP-FPM 架構，可能影響父程序關聯與事件呈現方式，因此企業應依實際環境進行驗證。

了解 Bitdefender EDR、XDR 與 MDR

5. Advanced Threat Control 與 Process Protection：阻止惡意程序行為

PHP2Shell 攻擊成功後，攻擊者可能嘗試啟動 Shell、建立子程序、下載工具或進行記憶體中的可疑操作。

Bitdefender Advanced Threat Control、Process Protection 及相關程序分析能力，可作為 EDR 之外的行為防護層，協助辨識：

Web Server 啟動命令列程序
從異常記憶體區域建立子程序
反向 Shell
檔案寫入與 Web Shell 行為
可疑工具下載
憑證竊取及權限提升

企業應確認相關模組已部署至 PHP 伺服器，並確認安全政策沒有過度寬鬆的排除項目。

了解 Bitdefender Process Protection

6. PHASR：降低漏洞被利用後的攻擊面

PHASR（Proactive Hardening and Attack Surface Reduction） 的角色不是修補 PHP 漏洞，而是降低攻擊者取得初始執行權限後可以繼續使用的工具與行為。

Bitdefender 官方分析提到，PHASR 可針對部分高風險行為進行阻擋或限制，例如：

whoami
certutil
curl 下載
PowerShell 下載
建立新帳號
修改本機管理員群組
建立排程工作
反向 Shell
Crontab 持久化

這類防護可降低攻擊者從「取得 PHP Worker 權限」進一步發展為「建立持久化、下載工具、提升權限或橫向移動」的機會。

不過，PHASR 的阻擋規則主要處理後續攻擊行為，不能取代 PHP 官方修補。建議企業先在監控或建議模式下觀察環境，再依業務需求逐步啟用阻擋策略。

了解 Bitdefender PHASR

7. Bitdefender MDR：由專家持續監控與追查

對於沒有 24 小時 SOC 或資安人力有限的企業，可評估導入 Bitdefender Managed Detection and Response（MDR）。

MDR 可協助：

24 小時監控安全事件
追蹤 PHP 相關端點活動
對執行 PHP 的主機進行威脅獵捕
分析 Shell、Web Shell、反向連線與工具下載
協助判斷事件嚴重度
提供事故回應與處置建議

Bitdefender 官方表示，MDR 團隊與 Bitdefender Labs 正持續監控 PHP2Shell 相關威脅。企業若缺乏足夠人力進行修補後回溯調查，MDR 可作為重要的營運補強。了解 Bitdefender MDR

六、建議企業採用的 Bitdefender 防護架構

情境一：企業有大量對外網站

建議優先部署：

EASM：找出所有對外公開 PHP 服務。
Risk Management：盤點受管理端點的 PHP 風險。
Patch Management：推動支援環境的修補。
EDR：追查 PHP Worker 後續程序行為。
PHASR：限制高風險工具及持久化行為。

情境二：企業主要使用 Linux Web Server

建議確認：

Linux 發行版是否在 Patch Management 支援範圍內。
PHP 是否由套件管理器安裝。
PHP 是否為自行編譯。
PHP-FPM 是否已納入 EDR 監控。
容器與主機是否分別納入盤點。
是否已設定適當的 EDR、ATC 與 PHASR 政策。

情境三：企業採用容器化部署

容器環境必須：

更新 Dockerfile 或基礎映像檔。
重新建置修補後的映像檔。
重新部署所有執行中的容器。
移除仍使用舊版 PHP 的舊映像。
檢查 CI/CD Pipeline 是否仍會拉取有漏洞版本。
對外部公開的容器服務進行 EASM 掃描。

只更新主機上的 PHP，不代表容器內的 PHP 已經修補。

情境四：企業沒有專職 SOC

建議至少採用：

Patch Management
EDR
PHASR
MDR

其中 Patch Management 負責修補，EDR 負責可視性與調查，PHASR 負責降低後續攻擊面，MDR 則補足全天候監控與回應能力。

七、企業可以採用的應變時程

0～4 小時：確認曝險範圍

找出對外 PHP 主機。
優先檢查 Apache mod_php。
確認 PHP-FPM、CGI、LiteSpeed 及容器環境。
盤點所有 PHP 分支與套件來源。

4～24 小時：完成高風險系統修補

更新對外服務。
重啟 PHP Worker。
替換容器映像檔。
確認所有負載平衡節點均已完成更新。
對無法修補的環境套用臨時限制。

24～72 小時：執行修補後調查

以 EDR 查詢 PHP Worker 的子程序。
檢查 Web Shell 與新建立的 Script。
搜尋可疑工具下載與反向連線。
檢查帳號、排程與持久化機制。
若發現入侵，立即旋轉密碼與 API 金鑰。

後續持續管理

將 PHP 納入正式資產管理流程。
將 PHP 版本與容器基礎映像納入修補政策。
建立重大 CVE 的緊急變更流程。
定期使用 EASM 檢查外部曝險資產。
使用 EDR 與 MDR 持續進行威脅獵捕。

結語：修補是第一步，持續偵測才是完整防禦

PHP2Shell 的核心風險，在於攻擊者不需要登入，也不一定需要利用網站應用程式漏洞。只要企業有未修補、對外提供 Web 請求的 PHP 環境，就必須立即確認曝險情況。

Bitdefender 的建議可整理為四個重點：

立即更新 PHP，不要只更新網站應用程式。
透過 EASM 與 Risk Management 找出所有受影響資產。
使用 Patch Management 落實修補與報告。
以 EDR、PHASR、Advanced Threat Control 及 MDR 追蹤並阻止後續攻擊行為。

Bitdefender GravityZone 的各項模組可以協助企業建立從外部資產盤點、漏洞風險辨識、修補部署、端點偵測到事件回應的完整流程；但任何端點防護模組都不能取代 PHP 官方修補，企業仍應將升級 PHP 視為本次事件的第一優先工作。

企業可先閱讀以下資料或有任何疑問可洽Bitdefender 台灣代理商德知士資訊以獲得更多訊息：