PHP2Shell 修補空窗期怎麼擋？Cloudflare 免費 WAF 導入請求與回應聯合偵測，六大邊緣防護措施與限制總整理

PHP 緊急安全更新釋出後，網站管理者仍需要時間確認環境、測試相容性並佈署修補。在這段期間，網站前端的防護服務能提供多少協助，成為這次事件的另一個焦點。

Cloudflare 於 10 月 21 日公布 PHP2Shell 防護佈署，涵蓋免費與付費 WAF （網頁應用程式防火牆）使用者，並首次以新的請求與回應聯合偵測能力，提供針對這次漏洞的受管防護。

PHP2Shell 是 CVE-2026-109618 與 CVE-2026-109619 兩個 PHP 漏洞的通稱，依 Cloudflare 說明由 Calif.io、Wiz、OpenAI 與 Quarkslab 於 10 月 21 日揭露，Sophos 與 AWS 等業者的公告也沿用此名稱。CyberQ 先前已報導 PHP 漏洞提前外洩與應變準備，以及官方修補版本與技術概要，以及如何在官方原始碼與編譯版套件發布前進行緩解和自動更新。這次延伸報導則從網站前端的防護機制，檢視 Cloudflare 與其他主要業者如何協助管理者降低修補期間的風險。

Cloudflare 是什麼？為何能在網站前方攔截攻擊？

Cloudflare 提供 DNS、內容傳遞網路（CDN）、DDoS 防護與網頁應用程式防火牆（WAF）等服務。網站將流量導向其代理網路後，訪客的連線會先經過 Cloudflare，再由它視需要轉送至實際提供服務的來源伺服器。

這種反向代理架構，讓加速與安全檢查可以在網站主機外執行。不過，僅使用 Cloudflare 的 DNS 服務，並不代表網頁流量已經過 WAF。依 Cloudflare 文件，DNS 紀錄的代理狀態決定 HTTP 與 HTTPS 流量是否經過其網路，標示為僅 DNS（DNS-only）的紀錄會直接回應來源伺服器的實際 IP，流量不會經過 Cloudflare。管理者仍須確認相關網域的代理狀態與流量路徑。

另一個容易忽略的繞過路徑，是來源伺服器的 IP 仍可被直接連線，這類請求同樣不會套用 WAF 規則。Cloudflare 的來源保護文件指出，DNS 紀錄屬公開資訊，接入後應更換來源 IP，並列出 Authenticated Origin Pulls、Cloudflare Tunnel，以及僅允許特定標頭或 JWT 流量等做法，確保連線來自 Cloudflare。

免費方案納入防護，付費使用者仍應確認阻擋模式

依這次的的 Cloudflare 說明，預設防護從台灣時間 10 月 21 日上午 11 時 02 分起生效。這次防護分成請求端與回應端兩組規則，適用方案與設定並不相同。

請求端的規則名稱為 Generic Rules – Anomalous Execution 1 至 7。免費方案的規則位於 Cloudflare Managed Free Ruleset（Ruleset ID 77454fe2d30c4220b5701f6fdfb893ba），不需另外啟用。Pro、Business 與 Enterprise 方案的規則位於 Cloudflare Managed Ruleset（Ruleset ID efb7b8c949ac4650a09736fc376e9aee），應確認該規則集已佈署且使用阻擋模式。兩個方案的規則名稱相同，但規則 ID 不同，查詢事件時須依自己的方案核對官方列出的 ID。

回應端則是新的 Cloudflare Managed Response Firewall Default，所有方案適用，含免費方案。官方列出的規則為 Default block for High confidence Signatures（規則 ID afffe22785674c80a31875c848d2242a），Cloudflare 並表示規則描述之後會更新。

Cloudflare 也表示，已觀察到攻擊者修改攻擊內容、嘗試繞過規則，因此持續調整防護。管理者可在 Security > Security Analytics > Events，依官方列出的規則 ID 查看命中事件、處置動作與路徑。

對網站維運而言，規則命中紀錄可以協助掌握攻擊活動，但仍須與主機端紀錄交叉判讀，才能進一步評估影響。

把 HTTP 請求與回應放在一起判斷

Cloudflare 在另一篇技術說明介紹 full transaction detection，也就是將同一次 HTTP 互動的請求與回應一起分析。

請求內容可以顯示可疑行為，回應則補充應用程式實際處理的結果。兩者關聯，有助提高判斷信心並減少誤判。回應規則命中後，可以在內容送達請求者之前，將來源伺服器回應替換為阻擋頁面。

這項機制值得關注的地方，是讓防護判斷多了一層結果資訊。對管理者而言，同一條可疑路徑究竟遭拒絕，或已回傳不該公開的資料，會影響後續調查的優先順序。

回應遭攔截，不代表來源主機沒有受到影響

Cloudflare 明確指出，回應階段的阻擋無法撤銷來源伺服器已執行的動作。這也是理解新功能時，最需要掌握的界線。因此，若看到 WAF 阻擋事件，不能單憑這項紀錄就認定主機安全。對維運團隊而言，仍應視事件內容檢查來源主機，並完成 PHP 更新。

另外，所有方案都能建立自訂回應規則，官方列出的上限為三條，動作限於記錄與阻擋，自行針對回應本文內容撰寫規則的能力尚未開放。

CyberQ 實測，免費與付費方案在偵測能力上仍有差異。Cloudflare 方面也對外說明，後續將比照請求端偵測的做法，免費方案的受管偵測聚焦於高知名度漏洞，付費方案則提供較豐富的偵測目錄。cf.waf.signature.response.* 這組偵測結果欄位僅提供付費方案使用，且 Cloudflare 說明仍在逐步開放，部分帳號尚未取得，需洽客戶團隊，簡單說就是要你花錢買才有更好的服務啦。

其他業者怎麼因應

PHP2Shell 並非只有 Cloudflare 提供邊緣防護，以下是 CyberQ 實務工作上碰到各家客戶使用的情形，也依各業者公告做說明。

業者	公布的措施	需注意
AWS WAF	Core rule set 的 SizeRestrictions_BODY 規則可針對超過 8 KB 的請求本文提供額外防護，對應 CVE-2026-109618。AWS WAF PHP Managed Rule Group 2.3 版已設為全球預設版本，新增 CVE-2026-109619 防護。另提供自訂規則範例，比對含 PHP_SESSION_UPLOAD_PROGRESS 的 POST 請求	AWS 稱 WAF 規則是支援修補的邊緣層，並非修補本身
Akamai	表示 App & API Protector 客戶已受保護，對應規則為 Adaptive Security Engine 3000991 v1	各方案涵蓋範圍與啟用狀態可再觀察
Azure WAF	Front Door WAF 受管規則 99006001（規則群組 MS-ThreatIntel-Response-CVEs）預計 10 月 28 日前完成推出，屬回應端偵測，會移除回應中的惡意內容而不阻擋流量。Application Gateway WAF 目前提供標頭改寫緩解，受管規則稍後推出	該規則預設停用，須自行啟用並將動作設為 Block on anomaly，且回應端緩解不產生 WAF 紀錄與命中次數。Azure 另提供自訂規則，並表示只降低特定攻擊面，不提供完整防護
Bunny Shield	三條受管 WAF 規則，涵蓋 session upload progress 與 multipart 巢狀欄位等請求樣態	僅在 WAF 為阻擋模式時才會阻擋
Imunify360	10 月 21 日釋出規則集 8.83 至 8.85，封鎖已知攻擊工具與請求樣態	屬主機端 WAF，涵蓋範圍依 ModSecurity 或 LiteSpeed 環境而異，仍需更新 PHP

從各家公告可以觀察到三點。第一，Azure 同樣運用回應端訊號，但處置方式是移除回應中的惡意內容，與 Cloudflare 以阻擋頁面取代回應不同，紀錄行為也不同。第二，各家預設狀態不一，Azure 受管規則預設停用，Bunny 須阻擋模式，Cloudflare 付費方案須確認阻擋模式，管理者不宜假設防護已自動生效。第三，各家都提醒仍須更新 PHP，而多家規則針對的是特定請求樣態，PHP 官方對 session 相關設定也表示只能阻擋已確認的攻擊路徑，不含其他變體，因此邊緣規則的保護範圍不宜過度解讀。

防護是否有效，必須放回完整的維運流程

CyberQ 認為，這次事件凸顯了網站安全的兩個不同時程。平台業者可以集中更新規則，網站管理者則必須逐一確認正式環境、相依套件與服務重啟。兩者之間的時間差，是前端防護能發揮價值的地方，它提供的緩衝，應用來加速完成修補。

CyberQ 指出，對缺乏專職資安人力的小型網站而言，免費方案取得受管防護有實際意義，管理者不必先具備編寫攻擊特徵的能力，就能開始運用這一層防線。但免費方案的偵測範圍以高知名度漏洞為主，進階的偵測欄位與較完整的目錄屬於付費方案，加上多家業者的規則針對特定請求樣態，防護範圍有其邊界。網站由誰維護、PHP 由誰更新、主機商何時完成佈署，仍需要明確的責任分工。若沒有確認完成的機制，更新通知很容易停留在「已經轉告廠商」，然後呢，就沒有後續了噢。

這次新增的回應偵測，也讓事件判讀更值得重視。CyberQ 建議，管理者處理告警時，至少先去關切了解這些流量是經過哪一層、在哪個階段被攔截，以及來源主機是否出現對應異常。這些問題比單看阻擋次數，更接近網站的實際風險。

對企業或代管多個站台的團隊，則可以把此次事件轉化為一份持續維護的確認紀錄，包括各站台的代理狀態、來源 IP 是否可被直接連線、使用的 WAF 業者與規則啟用狀態、規則處置、PHP 更新責任人與完成時間。未來再遇到共用軟體元件的重大漏洞，就能從已知的環境與責任分工開始處理，減少緊急事件中的反覆查找。