2026-10-22
科技趨勢

全球近 7 成網站跑 PHP。漏洞公開的那一晚,你的 WAF 在做什麼?

 

PHP2Shell(CVE-2026-109618/CVE-2026-109619)CVSS 9.2,不用登入就能遠端執行程式碼。Cloudflare 的防護規則,在 PHP 官方修補版釋出前就已預設上線。

 

預約 15 分鐘 WAF 曝險檢視 了解 WAF 移轉方案

 

 

10 月 21 日,發生了什麼事

10 月 21 日晚間,PHP 官方釋出緊急安全更新,修補兩個 CVSS 9.2 的嚴重漏洞。資安署同夜透過 N-ISAC 與 TWCERT/CC 通報各機關與企業。

 

這不是「例行更新」。報導指出,漏洞細節在官方公告前就已外洩;荷蘭政府讓部分入口網站暫時離線,連國家網路安全中心自己的網站也下線。

 

WordPress、Drupal、Joomla、Magento——所有建在 PHP 上的網站,都在名單內。

 

項目 內容
漏洞編號 CVE-2026-109618、CVE-2026-109619(業界稱 PHP2Shell)
嚴重度 CVSS v4.0 皆為 9.2;未登入即可遠端執行任意程式碼
官方修補版 PHP 8.5.12、8.4.27、8.3.36、8.2.35(僅支援中的分支)
影響範圍 已知伺服器端技術的網站中,約 75% 使用 PHP(Techzine);Cloudflare 引用 W3Techs「近 70%」

資料來源:中央社/聯合新聞網、Techzine、Cloudflare Blog

 

漏洞公開前,誰已經上線防護?

PHP2Shell 事件時間軸

圖 1 PHP2Shell 事件時間軸(UTC,2026-10-21)。資料:Cloudflare Blog、CERT-EU、Techzine

Cloudflare 的防護在 10 月 21 日 03:02 UTC 預設上線,Free 與付費方案都涵蓋;PHP 官方修補版則在 13:30 UTC 才釋出。中間約 10 小時,就是「公開前已先擋」的差距。

 

時間(UTC) 事件
03:02 Cloudflare 防護規則預設上線,涵蓋 Free 與付費方案
13:30 PHP 官方釋出安全修補版

 

防護比官方修補版早約 10 小時。不是因為預測得準,而是 Cloudflare 與 PHP Foundation 等團隊協同處理,並在攻擊流量出現前就把規則推到全球網路。

預設開啟,不需要客戶做任何動作:Free 方案客戶不需要任何設定;付費方案請確認 Managed Ruleset 為 Block 模式。

 

Cloudflare 自述防護領先「約 9 小時」;依 03:02 與 13:30 UTC 兩個公布時間點計算,差距為 10 小時 28 分。資料來源:Cloudflare Blog、Techzine

 

Cloudflare 這次用的新能力:Full transaction detection

傳統 WAF 只看請求。Cloudflare 這次首次在管理規則中使用「完整交易偵測」——同時分析同一筆 HTTP 交易的請求與回應,必要時在 origin 回應送出前攔下。

 

規則集 說明
Free 方案:Cloudflare Managed Free Ruleset Generic Rules - Anomalous Execution 1–7(共 7 條)
付費方案:Cloudflare Managed Ruleset Generic Rules - Anomalous Execution 1–7(共 7 條)
全方案:Managed Response Firewall Default 高信心特徵預設阻擋(1 條回應端規則)

資料來源:Cloudflare Blog。完整規則 ID 可參考原廠文章,查詢日誌時建議以規則 ID 篩選。

 

這不是第一次

Confluence 零時差(CVE-2022-26134,2022)

Confluence 零時差事件

圖 2 Confluence 零時差事件(UTC)。資料:Cloudflare Blog『Detecting zero-days before zero-day』

Atlassian 公告後約 3.5 小時,Cloudflare 規則全球上線。實際攻擊流量要再過 10 個小時以上才出現在日誌裡——也就是說,這 10 個小時裡,使用 Cloudflare 的系統是被擋住的。

 

時間(UTC) 事件
2022-06-02 20:00 Atlassian 發布漏洞公告
2022-06-02 23:38 Cloudflare 規則全球部署
2022-06-03 10:30 Cloudflare 日誌首次觀察到實際攻擊命中

資料來源:Cloudflare Blog:Detecting zero-days before zero-day

 

Log4Shell(CVE-2021-44228,2021)

Cloudflare 官方說法:漏洞公開後,所有使用 Cloudflare WAF 的客戶在不到 17 小時內受到全球保護,並以阻擋動作確保攻擊不會到達客戶應用程式。Forrester 在 2022 年 WAF 評估中,將 Log4Shell 列為 Cloudflare 的標竿案例。

資料來源:Cloudflare Blog:Cloudflare named a Leader in WAF by Forrester

 

持續不斷的緊急發布

Cloudflare 的 WAF 規則平時每週更新;遇到新漏洞時,會在例行週期之外進行「緊急發布」。近期官方紀錄如下:

 

日期 緊急發布內容
2026-09-10 Adobe Commerce/Magento 高嚴重度、已遭利用的零時差 RCE(CVE-2026-75650)
2026-10-14 常見網頁框架的重大遠端程式碼執行(RCE)漏洞,新增 Generic Rules - Remote Code Execution,預設 Block
2026-10-21 Free 與 Managed Ruleset 同步緊急發布 PHP2Shell 防護規則

資料來源:Cloudflare WAF 更新日誌、2026-09-10 緊急更新、2026-10-14 緊急更新

 

我們不說「裝了就安全」

漏洞公開當天的兩層動作。

圖 3 漏洞公開當天的兩層動作。資料:Cloudflare Blog 建議行動

WAF 是創可貼,不是手術。

沒有人能保證規則 100% 擋下所有變形。攻擊者在規則上線後數小時就開始改 payload,Cloudflare 自己也這麼說。所以我們給客戶的建議永遠是兩件事:

 

  • 今晚:確認 WAF 為 Block 模式、規則已啟用,爭取時間。
  • 本週:升級 PHP 本體(不是只更新外掛)。

 

另外要注意:繞過 Cloudflare、直連主機 IP 的流量,WAF 不會保護你。我們會一併檢查你的 origin 是否真的只接受 Cloudflare 的連線。

資料來源:Cloudflare Blog。更新網站程式碼或外掛無法取代 PHP 執行環境的安全更新;限制上傳也不能取代修補。

 

用別家 WAF/CDN?這是重新比較的時間點

一份防護合約簽三年,換約那天才想起要比較,是最貴的時機。這次事件之後,請問你的供應商三個問題:

 

  1. 漏洞公開之前,規則有沒有上線?還是公開之後才開始?
  2. 規則預設是 Block,還是需要我自己去後台開?
  3. 我要去哪裡確認這條規則有沒有命中?日誌能不能直接看到攻擊嘗試?

 

三題裡有任何一題答不出來,我們建議你做一次檢視。

 

移轉不用付兩次錢

「我現在合約還沒到期,現在換等於付兩份錢。」——這是客戶最常見的顧慮,也是我們設計移轉方案的起點。

不想為了「想比較」就付兩次錢?樂雲提供移轉方案,讓你在現有合約期間內,就能先把 Cloudflare 與舊平台並行運作、驗證,再決定何時正式切換。

 

付款安排與適用條件,依你目前的合約狀況量身規劃——方案內容請洽樂雲,我們會在 15 分鐘檢視時一併評估。

 

為什麼需要並行期

搬 WAF 的風險不是「上線」,而是「切換那一刻」。並行期讓你:

 

  • 先用「僅記錄(Log)」模式跑一週,看誤擋率
  • 確認 origin 鎖定為只接受 Cloudflare 來源
  • 在不影響線上的前提下,一條一條把舊規則對應過來
  • 確認沒問題才把 DNS 切換過去

 

參考資料:Cloudflare 零停機遷移說明。此文件以 Cloudflare for SaaS 為例,一般網站的切換流程仍須依實際架構評估。

 

不是 Cloudflare 客戶,也能先做這三件事

  1. 盤點所有跑 PHP 的系統,包括「不會告訴你它跑 PHP」的後台與套件。
  2. 升級到 8.5.12/8.4.27/8.3.36/8.2.35(或你所用分支的 backport)。
  3. 檢查近 48 小時日誌有沒有異常 POST(特別是 multipart/form-data 與檔案上傳)。

 

15 分鐘免費檢視:你的網站現在擋得住 PHP2Shell 嗎?

 

我們會看:WAF 模式、規則啟用狀態、origin 是否裸露、PHP 版本。如果你正在用其他廠牌,也可以一併做移轉評估與費用試算。

 

預約檢視

 

參考資料

我們使用 Cookie 以允許我們網站的正常工作、個性化設計內容和廣告、提供社交媒體功能並分析流量。我們還同社交媒體、廣告和分析合作夥伴分享有關您使用我們網站的信息

管理Cookies

隱私權偏好設定中心

我們使用 Cookie 以允許我們網站的正常工作、個性化設計內容和廣告、提供社交媒體功能並分析流量。我們還同社交媒體、廣告和分析合作夥伴分享有關您使用我們網站的信息

查看隱私權政策

管理同意設定

必要的Cookie

一律啟用

網站運行離不開這些 Cookie 且您不能在系統中將其關閉。通常僅根據您所做出的操作(即服務請求)來設置這些 Cookie,如設置隱私偏好、登錄或填充表格。您可以將您的瀏覽器設置為阻止或向您提示這些 Cookie,但可能會導致某些網站功能無法工作。