PHP2Shell 修補與防護指南：PHP 更新、ModSecurity 規則與入侵跡象檢查

更新日期：2026-10-24。本文搭配 RuleArena 的 PHP2Shell 影片，提供網站負責人與維運人員可以分工執行的處理方式。規則與門檻是本文的防禦範例，適用條件與驗證範圍列在後面。

你在 WordPress 後台更新了網站和外掛，網站看起來一切正常，接著才發現：主機上的 PHP 仍然是舊版。

這正是 PHP2Shell 最需要釐清的地方。漏洞位於執行網站程式的 PHP 核心；研究團隊已在特定 WordPress、Drupal、Joomla 測試環境示範未登入的遠端程式碼執行，也展示了敏感記憶體讀取。網站使用哪一套 CMS，無法單獨決定是否受影響。研究團隊說明

處理順序：確認實際使用的 PHP → 套用修補並重啟 → 等待期間限制入口與請求 → 檢查是否已有入侵跡象。本文會把 ModSecurity 的設定寫出來，讓沒有商用 WAF 的網站，也能建立可檢查的暫時防護。

先依你的工作找到要做的事

WAF（網站應用程式防火牆）是在網站前檢查 HTTP 請求的防護層；SIEM 則把多處日誌集中起來，方便比對同一時間發生的事。本文的設定段落可交給維運人員執行，網站負責人先確認修補與責任分工即可。

一、PHP2Shell 為什麼會危險？

這次研究涵蓋兩類記憶體安全問題，分別以兩個 CVE 追蹤：

攻擊成功時，程式通常以網站工作程序原有的權限執行。例如，購物網站原本能讀取資料庫連線設定，攻擊者就可能利用這些權限讀取訂單；若程序能修改網站目錄，也可能竄改網頁或留下後門。這些是依程序權限推演的後果，不能直接等同於取得主機 root。

部分 Apache mod_php 路徑會在網站程式執行前出問題，因此 WordPress 登入檢查、防護外掛或維護模式頁面，可能還沒有機會介入。其他部署如 PHP-FPM 也要評估與修補，但利用條件不完全相同。OOM 官方公告、跨請求狀態官方公告

已有安全團隊在蜜罐觀察到攻擊嘗試；這足以支持優先修補，不能據此聲稱每一個被掃描的網站都已入侵成功。AWS 原始觀察

二、治本：更新「網站正在使用」的 PHP

原始兩個 CVE 的第一個上游修補版本如下。實際作業應採用對應分支含修補的維護版本，並對照主機商或套件供應商公告。

放大查看 ↗

圖 1｜PHP 官方 2026-10-21 公告列出的首批修補版本，原頁局部截圖。這些版本對應原始兩個 CVE；供應商回補及後續公告仍須另外核對。來源：PHP 官方

發行版可能將修補回補到原有套件，所以完整套件版本與供應商公告，比單看上游版號更可靠。8.1 與更舊分支需另外確認供應商維護；PHP 也曾提供部分舊分支的最小原始碼回補，不能一概認定所有舊版都完全無修補。PHP 官方公告

維運人員要逐一核對網站、FPM pool、容器與不同主機上的 PHP。終端機的 php -v 只能證明那個 CLI 的版本；它不保證網站使用同一套執行環境。若以臨時網頁確認版本與設定，應限制存取並在核對後移除，不要公開完整 phpinfo()。

完成更新後，重新啟動所有相關 PHP 工作程序；使用 mod_php 時也要處理承載它的 Apache 程序。再測試登入、聯絡表單、圖片上傳、付款與排程等實際功能。更新與重啟說明

如果你沒有主機管理權限，可以直接把這段交給主機商：

請協助確認本網站實際使用的 PHP runtime，是否已修補 CVE-2026-109618 與 CVE-2026-109619，並提供套件版本或對應公告。請同時確認相關工作程序已載入更新；若尚未完成，請告知修補時程、等待期間的入口限制，以及 session.upload_progress.enabled 的設定狀態。

三、等待更新時，先做哪些暫時措施？

先依網站用途選擇，不必從購買設備開始。

先停用不需要的上傳進度追蹤

由維運人員在請求解析前就生效的 php.ini、FPM pool 管理設定或對應伺服器設定中處理：

session.upload_progress.enabled = 0

改完後重啟相關工作程序。這會停用 PHP 的上傳進度追蹤，普通檔案上傳功能並不因此全面關閉。不要把這項設定只放在應用程式的 ini_set()，也不要依賴 FPM 的 .user.ini 來處理這個早期路徑。它能阻斷已確認的 session 相關路徑，仍有其他變體需要正式修補。官方暫時措施、功能說明

2026-10-23 補充公告需另外看待：PHP 公布另一項上傳進度風險 CVE-2026-115560，條件包含原設定使用 php_binary 或 php_serialize，應用程式又在執行期間切換成 php 再呼叫 session_start()，且上傳進度仍開啟。先前已停用者應保留設定，等後續官方修正版再確認；從不在執行期間切換處理器的應用，官方說明可維持功能開啟。這項新公告不表示 10 月 21 日對原始兩個 CVE 的修補全面失效。PHP 10/23 公告

放大查看 ↗

圖 2｜PHP 官方 2026-10-23 補充公告的原頁局部，提醒已停用上傳進度者繼續保留設定。完整適用條件見上段及原公告；這張圖不是所有 PHP 部署皆符合新問題條件的證明。來源：PHP 官方

進階設定交給管理員評估

PHP 8.5 的 fatal_error_backtraces=0 可暫時移除其中一條已確認路徑，變更後應重新啟動所有相關工作程序，避免沿用既有殘留狀態。FPM 的 pm.max_requests=1 會讓工作程序更頻繁回收，需評估效能，也不涵蓋所有機制。跨請求狀態公告

官方亦列出 memory_limit=-1，用來移除可控的 PHP 單次請求記憶體上限。本文附件不預設啟用它。底層記憶體配置失敗仍可能走入漏洞路徑，而且資源耗盡可能造成程序或服務中斷；必須由管理員連同容器／cgroup 界線評估。採用者還要由管理層強制設定，確認其他 pool、目錄與應用程式設定沒有覆寫回有限上限，並重新啟動所有相關工作程序。不要以 RLIMIT_AS 或 RLIMIT_DATA 代替，官方明確提醒這可能造成所要避免的配置失敗。修補後也應重新檢視正常的記憶體限制。OOM 暫時措施與限制

四、ModSecurity 加 OWASP CRS，怎麼成為自架 WAF？

ModSecurity 是檢查 HTTP 流量並執行規則的引擎；OWASP Core Rule Set（CRS）提供通用攻擊偵測規則。把它們放在原網站前面的反向代理，就能在請求進入 PHP 前先檢查流量。

放大查看 ↗

圖 3｜RuleArena 自製請求流程示意，以獨立前置 WAF 代理為例。Phase 1 是請求標頭檢查；讀取 body 時套用大小限制，之後由 Phase 2 檢查已解析內容。應在後端處理前完成拒絕；實際介入位置仍須用 connector 與後端紀錄驗證。依據：ModSecurity 處理階段

有 Nginx 的環境，可使用受維護的 libModSecurity v3 與相容的 Nginx connector。Apache 的常見組合是 ModSecurity v2；本文參考檔與離線驗證以 v3 為主，不將同一份設定宣稱已在所有引擎上驗證。CRS 安裝文件、Nginx connector

使用 Docker 的人也能從 OWASP CRS 官方容器開始，指定後端服務、載入自己的規則，再處理 TLS 與網路設定。這類工具可自行部署，但主機資源、版本更新、誤擋調整與監控仍需要維護。

只有 WAF 入口對外，原站應限制為接受 WAF 轉送。如果原站 IP、另一個連接埠或測試網域仍可直接連到 PHP，攻擊者就可能走沒有經過規則的路徑。HTTPS 也必須在能解密並檢查內容的位置套用防護。

CRS 有規則，不等於已有完整 PHP2Shell 防護

截至本文查核，未找到 CRS 官方針對這兩個 CVE 公開的完整阻擋驗證聲明。官方掃描器 User-Agent 清單雖有 php2shell，它辨識的是使用者代理字串，不能拿來證明已攔下漏洞利用。官方資料檔

本文接下來提供的是請求限制與解析錯誤阻擋政策。這些條件可以測試，也有明確適用範圍；它們不是從某個攻擊樣本抽出、已驗證涵蓋所有變體的 CVE 特徵。

五、先設定共同基線，再選 A 或 B

先確認你已經有受維護的 ModSecurity 引擎、對應 Web server connector，以及按官方文件載入的 CRS。附件是整合用的參考設定，不是安裝包；也不能把這些規則貼進 WordPress 的 wp-config.php 或外掛程式碼。沒有主機管理權限時，把需求交給主機商，不必先嘗試改規則。

請先在測試環境整合。本文以功能簡單的網站示範：整份 body 8 MiB、非檔案內容 128 KiB、最多 100 筆已解析參數。這些數字是範例門檻，不是 PHP2Shell 的安全界線。大型 WordPress 編輯畫面、批次上傳、匯入及複雜表單可能需要調整。

以下內容放在 10-php2shell-common.conf，整合於引擎官方基礎設定之後：

SecRuleEngine On
SecRequestBodyAccess On
SecRequestBodyLimit 8388608
SecRequestBodyNoFilesLimit 131072
SecRequestBodyLimitAction Reject

SecArgumentsLimit 101

SecRule &REQUEST_HEADERS:Content-Type "@gt 1" \
    "id:1101002,phase:1,deny,status:400,log,auditlog,t:none,msg:'RuleArena policy: multiple Content-Type headers',tag:'rulearena/php2shell-exposure'"

SecRule INBOUND_DATA_ERROR "!@eq 0" \
    "id:1101003,phase:2,deny,status:413,log,auditlog,t:none,msg:'RuleArena policy: request body exceeded inspection limit',tag:'rulearena/php2shell-exposure'"

SecRule REQBODY_ERROR "!@eq 0" \
    "id:1101004,phase:2,deny,status:400,log,auditlog,t:none,msg:'RuleArena policy: request body parser error',tag:'rulearena/php2shell-exposure'"

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
    "id:1101005,phase:2,deny,status:400,log,auditlog,t:none,msg:'RuleArena policy: multipart strict validation failed',tag:'rulearena/php2shell-exposure'"

SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" \
    "id:1101006,phase:2,deny,status:400,log,auditlog,t:none,msg:'RuleArena policy: multipart unmatched boundary',tag:'rulearena/php2shell-exposure'"

SecRule &ARGS "@gt 100" \
    "id:1101007,phase:2,deny,status:403,log,auditlog,t:none,msg:'RuleArena policy: more than 100 parsed arguments',tag:'rulearena/php2shell-exposure'"

這段設定有三個用意：

1. 啟用實際阻擋與 request body 檢查，明確設定超限時拒絕。只開 DetectionOnly 不會達成這個目的。
2. body 超限或解析失敗時拒絕請求，避免「WAF 沒有完整看懂，後端卻繼續處理」。
3. 將解析參數上限設為 101，並在數量超過 100 時阻擋。若把解析上限與政策都設成 100，再寫 @gt 100，集合可能根本不會增加到可觸發的數量。

引擎官方基礎設定可能已有同類錯誤檢查；整合時可合併重複功能，並保留清楚的載入順序。body 超限也可能先被引擎或前端攔下，所以不保證每次都由本文自訂 ID 回應。設定指令、官方基礎設定

本文 1101001 等編號是未登記的範例 ID，與 OWASP 官方或商用 IPS 特徵碼無關。部署前請按站內編號規劃檢查衝突，必要時重新分配。Rule ID 說明

方案 A：網站完全不需要 multipart

除了共同基線，再載入：

SecRule REQUEST_HEADERS:Content-Type "@rx (?i)^[ \t]*multipart/" \
    "id:1101001,phase:1,deny,status:403,log,auditlog,t:none,msg:'RuleArena policy: multipart disabled for this site',tag:'rulearena/php2shell-exposure'"

規則在 phase:1 檢查送到 WAF 的 Content-Type 宣告，不分 HTTP 方法，也不只套在 .php 網址。符合 multipart/ 前綴就直接拒絕，因此 multipart/form-data 及其他 subtype 都在此政策範圍。

這會擋住正常上傳，也可能擋住沒有附件的 multipart 表單。WordPress 媒體庫、編輯器及外掛功能，要先實際測試。只有「網站沒有讓訪客上傳檔案」仍不足以決定可以全站套用。

它不會嗅探所有原始 body，也不保證排除代理與 PHP 之間的解析差異；效果應表述為「縮小一類請求入口」。ModSecurity 與 PHP 解析差異

方案 B：網站必須保留檔案上傳

保留共同基線，不要載入方案 A，改用：

SecRule &FILES "@gt 5" \
    "id:1101008,phase:2,deny,status:403,log,auditlog,t:none,msg:'RuleArena policy: more than 5 parsed file entries',tag:'rulearena/php2shell-exposure'"

SecRule &MULTIPART_PART_HEADERS "@gt 300" \
    "id:1101009,phase:2,deny,status:403,log,auditlog,t:none,msg:'RuleArena policy: more than 300 parsed multipart part-header lines',tag:'rulearena/php2shell-exposure'"

這裡多看兩個指標：

第二條特別用來拒絕 metadata 過多的請求，減少它們進入 PHP 的機會。它計算整份請求的集合項目，並不是每個 part 的上限，也不是原始封包實體行數。檔案數、參數數與 metadata 數也無法直接換算成 PHP 最終記憶體用量。集合變數定義

這些規則在 WAF 解析 body 後執行，所以前面的總大小限制仍然需要保留。MULTIPART_STRICT_ERROR 也可能拒絕某些少見但合法的 multipart 格式；遇到誤擋應回查實際格式，針對必要功能調整。

目前這套範例主要處理一般表單與 multipart。JSON／XML 等 API 要確認官方基礎設定已選用正確的 body processor；REQBODY_ERROR=0 不能單獨證明未知格式已完成檢查。JSON 深度限制也不能當成 PHP 表單陣列深度限制。

不要把功能最低版本當作安全版本

本例使用的 SecArgumentsLimit、非檔案 body 限制與 multipart header 集合，在 v3 不同版本才陸續具備。更重要的是，ModSecurity 自己也有安全更新：官方 2026 年 9 月公告列出的多項問題，修正版本包含 3.0.17／2.9.15。

正式環境應採用仍受維護且包含相關安全修補的引擎、connector 與 CRS，並在實際組合重新驗證。不要因舊版能載入這幾條規則，就把舊版拿來新部署。ModSecurity 安全更新

六、讓規則真的擋在 PHP 前面

已有 Nginx 與 ModSecurity connector 的環境，需要在實際提供服務的設定中啟用：

# 放在實際受保護的 server 區塊；路徑按安裝位置調整。
modsecurity on;
modsecurity_rules_file /etc/modsecurity/rulearena/00-load-example.conf;
client_max_body_size 8m;

modsecurity on; 是 Nginx connector 開關，SecRuleEngine On 是引擎的阻擋模式，兩者都要確認。Connector 文件

在實際轉送的 location 中，使用與後端相符的 request buffering：

# 使用 proxy_pass 轉送 HTTP 後端：
proxy_request_buffering on;

# 若改用 fastcgi_pass 直接送到 PHP-FPM，使用這個對應設定：
# fastcgi_request_buffering on;

目的在於先讀取請求 body，再交給後端，並配合前端實際大小限制。不要只比較 Content-Length；沒有該標頭或使用分塊傳輸的請求，也要在實際部署測試。上述片段不能替代完整的 TLS、proxy header 與網路設定。Nginx body 限制、HTTP 代理緩衝、FastCGI 緩衝

載入順序示意如下；如果既有 CRS 已有 plugins、排除規則與初始化檔，保留其原本要求的順序，不要重複載入整套 CRS：

Include /etc/modsecurity/modsecurity.conf
Include /etc/modsecurity/rulearena/10-php2shell-common.conf

# A 或 B 選一個：
Include /etc/modsecurity/rulearena/20-profile-a-no-multipart.conf
#Include /etc/modsecurity/rulearena/20-profile-b-required-uploads.conf

Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

變更前保存原設定，先做語法檢查，再依維運流程 reload。若出現誤擋，退回的是這次特定變更，不是直接關閉所有 WAF；如果移除暫時措施，就要同步採用其他入口限制或加快修補。

七、用正常資料驗證，不必拿漏洞利用程式測正式站

先使用會回傳固定結果的測試端點，確認正常功能，再檢查拒絕政策。測試至少涵蓋：

你也可以短暫載入附件中的測試規則：

SecRule REQUEST_HEADERS:X-RuleArena-WAF-Test "@streq php2shell-policy-check" \
    "id:1101099,phase:1,deny,status:403,log,auditlog,t:none,msg:'RuleArena WAF routing canary',tag:'rulearena/test'"

再送出一個沒有攻擊內容的請求：

curl -i -H 'X-RuleArena-WAF-Test: php2shell-policy-check' \
  https://staging.example.com/__rulearena_waf_probe

預期看到 403 與對應規則紀錄，並確認後端沒有收到這筆請求。測試完移除 canary 規則。這只能驗證該路徑有執行這條規則；其他路由、body 解析和漏洞涵蓋仍需分別確認。

本文附件的驗證範圍

初稿附件所附的離線驗證紀錄記載：使用 libModSecurity C API，完成三種規則組合的載入，以及 41 個正常／超限合成交易案例；41 個均符合預期，另做了 5 個集合計數診斷。測試使用 Ubuntu 套件提供的 ModSecurity v3.0.12，僅作離線相容性基線，不是建議部署版本；過程沒有執行 PHP 或漏洞利用程式。

附件紀錄有兩個值得保留的觀察：第一，超過總 body 上限時，核心可能先提出 403 拒絕，非檔案內容超限則可由規則提出 413；驗證不能只看是否得到固定的 413。第二，此引擎將空檔名 part 計入 ARGS 而非 FILES，證實檔案集合不能代表全部 multipart parts。

詳細結果、規則 SHA-256 與重跑方式位於附件的 validation/。這次沒有測 Web server connector、整套 CRS、TLS、chunked 傳輸、PHP 解析差異、audit／SIEM 收集或實際 CVE 攻擊；結果只支持上述核心引擎政策行為。

把驗證分成三層，比只看「通過幾項」更容易判斷：

上線前仍要完成 Nginx／Apache connector、CRS、TLS、代理改寫、實際 PHP 部署與正常業務流程的整合驗證。附件保留測試方法與結果，方便在你的維護版本重跑。

八、把防護紀錄送進 SIEM，觀察哪些特徵？

開啟 audit log，才能回查哪些政策被觸發。下列是日誌配置示例；路徑、權限與保留時間要按環境設定：

SecAuditEngine RelevantOnly
SecAuditLogType Serial
SecAuditLog /var/log/modsecurity/audit.log
SecAuditLogParts ABFHZ
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

這個範例未選取完整 request／response body 區段，但不代表日誌沒有敏感資料。B／F 區段的標頭仍可能含 Cookie、Authorization 或 Set-Cookie；H 區段的告警訊息、matched data 或 logdata 也可能帶入參數片段。限制日誌存取、設定保留期限，並在送入 SIEM 與對外分享前核對遮罩範圍。Audit 設定說明

一般 CRS 命中會先累積異常分數，再由阻擋評估決定是否拒絕；本文的 deny 規則則是直接拒絕。看見命中 log 後，仍要核對最終回應與後端是否收到請求。CRS 異常評分

建議把下列訊號放在一起看，而不是只依賴某個固定字串：

研究團隊列出的調查線索包含異常 session cookie、multipart 搭配記憶體錯誤及 worker 重啟；同時提醒，有些路徑可能沒有明顯應用日誌。調查線索與限制

如果 PHP／FPM 錯誤訊息已寫入 Elasticsearch 的 message 欄位，可先用以下 KQL 狩獵查詢找出值得關聯的紀錄：

message : ("Allowed memory size" or "Maximum execution time" or "SIGSEGV" or "Segmentation fault" or "exited on signal")

再依主機、網站、FPM pool／PID、時間與 request ID 對照入口紀錄。這是通用異常搜尋，沒有宣稱能判定某一 CVE，也不應直接接成自動封鎖規則。若你的管線欄位不是 message，要換成實際解析後的欄位。

已經有商用 WAF／IPS 的環境，可以另外確認原廠公告、特徵版本、阻擋動作與 HTTPS 檢查位置；本文的 ModSecurity ID 不能直接貼進不同產品當作通用特徵碼。

九、修補後，還要確認有沒有留下入侵痕跡

更新 PHP 能修正漏洞，但不會自動刪除攻擊者之前寫入的檔案、帳號或排程，也無法收回已經外流的資料。

若發現異常，先保存相關日誌與檔案證據、限制受影響環境存取，再調查範圍、清除持續存取途徑，並處理可能外洩的資料庫密碼、Session、API 金鑰等。需要還原時，使用已知可信的程式碼與備份，再補齊安全更新。WordPress 事件處理參考

最後把維護責任寫清楚：WordPress 與外掛由誰更新、PHP 與作業系統由誰維護、WAF 規則由誰驗證、備份多久演練一次。下次收到安全公告，就能直接找到負責人和處理時程。

怎樣才算這次處理有交代？

• 已記錄每個網站實際使用的 PHP／套件版本、對應修補依據，以及工作程序重新載入的時間。
• 等待修補期間的入口限制或 A／B 政策有負責人、正常功能測試及退回方式；如有 WAF，已核對拒絕紀錄與後端沒有收到請求。
• 已檢查其他網域、連接埠與原站直連，並記下要追查的異常及其時間線。
• 已指定後續 PHP／WAF 更新、日誌與備份的維護責任；暫時措施不會因更新完成就被遺忘。

參考檔與後續維護

附件包含共用政策、A／B 兩套選配規則、Nginx 整合片段、PHP 暫時設定，以及可重跑的離線驗證資料。請選一個 profile，先核對正常功能再啟用。

這篇文章與 PHP2Shell 影片會互相連結；影片公開網址及 GitHub 規則下載位置，待發布時補上。此版本的依據截至 2026-10-24，後續 PHP／ModSecurity／CRS 公告應重新核對，尤其是 10 月 23 日新增的上傳進度問題。

封面為 AI 生成的概念插畫，用來表達網站、PHP 與前置防護的關係，不是漏洞利用或防護成效證據。圖 1、2 是 PHP 官方原頁局部；圖 3 是 RuleArena 自製教學示意，來源與適用條件各列在圖說。

主要一手來源

• PHP 安全公告與 2026 年發布紀錄
• PHP：RCE via OOM corruption
• PHP：RCE via stale global state
• PHP2Shell 研究團隊專頁
• ModSecurity 設定指令
• ModSecurity 變數與集合
• ModSecurity 官方基礎設定
• ModSecurity 2026 年 9 月安全更新
• OWASP CRS 安裝與整合
• OWASP CRS 官方 Docker 映像