PHP2Shell、Node2Shell 接連爆發：Cloudflare、Fastly、Akamai 與 AWS 如何應對重大 RCE 漏洞？

一、PHP2Shell 與 Node2Shell 是什麼？為什麼需要立即關注？

1. PHP2Shell：PHP 核心出現重大 RCE 漏洞

2026 年 10 月 21 日，PHP 公布兩項重大漏洞，分別為 CVE-2026-109618 與 CVE-2026-109619，合稱 PHP2Shell。兩項漏洞的 CVSS v4.0 評分均為 9.2，屬於重大風險。

漏洞涉及 PHP 執行環境的記憶體安全與請求處理機制。攻擊者可能透過特製 HTTP 請求觸發底層錯誤，造成遠端程式碼執行、資料暴露或服務中斷。由於攻擊路徑可能從一般網路請求進入，未及時更新的網站與應用程式需要特別留意。

PHP 公布的修補版本包括：PHP 8.5.12、PHP 8.4.27、PHP 8.3.36、PHP 8.2.35。

較舊的 PHP 版本則需要依維護狀態、發行套件及供應商公告確認可用的修補方式。AWS 威脅情報也指出，曾在漏洞公開前觀察到相關利用活動，顯示攻擊風險不只停留在理論層面。

2. Node2Shell：Node.js Brotli 解碼器的記憶體安全問題

另一項漏洞為 CVE-2026-111497，名稱為 Node2Shell，由 Node.js 使用的 Brotli 解碼器中的越界寫入問題引起。當應用程式處理特製的 Brotli 壓縮資料時，可能造成記憶體破壞，進一步導致程式崩潰、記憶體資料暴露，甚至遠端程式碼執行。

值得注意的是，受影響情境不只限於直接呼叫 Brotli 解碼 API 的應用程式。依應用程式的處理方式，內建 fetch() 的回應解壓縮流程，以及 Express 5 等會處理 Brotli 壓縮請求本文的應用程式，也可能受到影響。

Akamai 於 10 月 26 日發布技術分析，指出其遙測資料顯示，61% 的網路仍在使用受影響的 Node.js 版本。這項數據反映受影響環境可能相當普遍，但不代表所有相關網路都已遭到攻擊。

Node.js 已針對受支援的版本分支發布修補版本，包括 22.23.4、24.22.1 與 26.12.1。企業應依實際使用版本及官方公告確認更新需求。

3. 兩起漏洞帶來的共同挑戰

PHP2Shell 與 Node2Shell 涉及不同的底層問題，但對企業而言，都帶來幾項相似的應變挑戰：

• 漏洞可能透過網路請求觸發：企業需要確認對外服務是否使用受影響的執行環境，以及相關入口是否能被外部存取。

• 更新不一定能立即完成：正式修補可能涉及相依套件、應用程式相容性、測試與維護時段。

• 攻擊方式可能持續變化：單一請求特徵未必能涵蓋所有利用方式，需要持續更新偵測邏輯。

• 防護規則也可能影響正常服務：過於廣泛的封鎖條件，可能讓合法請求、API 或圖片服務受到影響。

因此，企業需要將軟體修補、邊界防護、資產盤點與流量監控納入同一套應變流程，而不是只依賴單一安全措施。

二、Cloudflare：提前部署防護，並觀察完整交易行為

PHP2Shell：在漏洞公開前部署 WAF 防護

Cloudflare 表示，針對 PHP2Shell 的 WAF 防護自 10 月初便開始部署，並於漏洞公開前約九小時完成上線。自 10 月 21 日 03:02 UTC 起，啟用 Cloudflare WAF 的免費及付費客戶，便預設受到已知攻擊手法的防護。

除了針對請求特徵建立規則，Cloudflare 也公布 Full Transaction Detection（完整交易偵測）機制，將同一筆 HTTP 交易中的請求與來源伺服器回應一併分析，藉此辨識可能的漏洞利用行為。

搭配 Response Rules，系統可在符合條件時，於可疑的來源伺服器回應傳送給請求者之前進行攔截。這種方式不只分析請求本身，也將應用程式處理請求後的回應納入判斷。

Cloudflare 另指出，攻擊者持續變更攻擊 payload，嘗試繞過既有規則，因此需要透過命中量與規則邏輯持續檢視攻擊變化。

10 月 22 日，Cloudflare 更新了七條既有規則的名稱與中繼資料，使其明確對應兩項 PHP2Shell CVE。這次公告主要是既有規則的標示更新，而非當天才首次部署防護。

Node2Shell：先記錄命中，再由客戶評估是否封鎖

10 月 25 日，Cloudflare Managed Ruleset 新增兩條與 Node2Shell 有關的規則：

Brotli 規則：比對帶有 Content-Encoding: br 的請求本文。

Next.js 規則：比對 Next.js 圖片最佳化端點 /_next/image 的請求。

兩條規則預設均採用 Log 動作，先記錄符合條件的請求，而非直接封鎖。

原因在於，符合這些條件的請求也可能是正常流量。例如，合法客戶端可能傳送 Brotli 壓縮的請求本文，Next.js 網站也可能正常使用圖片最佳化端點。若直接封鎖，可能造成合法請求失敗或圖片無法正常載入。

Cloudflare 的作法，是先讓客戶觀察規則命中情況，再依照實際應用程式環境決定是否採取封鎖措施。

這也說明，緊急 WAF 規則不一定都應採取立即封鎖的方式。當偵測條件與正常流量有所重疊時，先取得可見性、再評估阻擋策略，能降低防護措施對服務的影響。

三、Fastly：透過 Virtual Patching 降低修補前的風險

Fastly 分別針對 PHP2Shell 與 Node2Shell 發布防護公告，將緩解措施整合至客戶既有的 Next-Gen WAF 工作流程。

PHP2Shell：提供可啟用的虛擬修補

10 月 21 日，Fastly 宣布 PHP2Shell 的 Virtual Patch 已可供客戶使用，將 CVE-2026-109618 與 CVE-2026-109619 整合為一組虛擬修補。

Fastly 指出，PHP2Shell 涉及 PHP 執行環境底層的錯誤處理機制，因此 WAF 防護只能降低風險，無法取代正式更新。若企業無法立即修補，主動緩解措施仍可能存在防護缺口，也可能需要限制部分合法流量。

Node2Shell：提供虛擬修補與自動套用機制

10 月 26 日，Fastly 宣布 CVE-2026-111497 的 Virtual Patch 已可使用。啟用 Automatic CVE Virtual Patching 的工作區，會自動取得這項修補；其他客戶則需要進入 Next-Gen WAF 控制台啟用。

Fastly 的做法，是將漏洞應變整理成客戶能在既有 WAF 工作區中使用的防護措施，並透過自動化設定降低手動追蹤與部署規則的負擔。

對企業而言，虛擬修補能提供較快速的緩解方式，尤其適用於需要時間測試與部署正式更新的環境。但實際防護效果仍取決於規則涵蓋範圍、應用程式設定與攻擊路徑，不能視為完整修補的替代品。

四、Akamai：從 WAF 防護延伸至漏洞研究與資產盤點

Akamai 的應變涵蓋邊界防護、技術分析，以及受影響資產的辨識與隔離。

PHP2Shell：更新應用程式防護規則

Akamai 表示，App & API Protector 客戶已受到相關安全更新保護，並透過 Adaptive Security Engine 規則 3000991 v1 偵測 PHP 遠端程式碼執行攻擊。Akamai 也指出，既有命令注入規則可緩解部分已武器化的攻擊 payload。

Node2Shell：提供技術分析與受影響資產建議

10 月 26 日，Akamai 發布 Node2Shell 深入分析，說明漏洞成因、受影響版本與緩解方式，並向受影響的 Akamai Enterprise Application Access（ExAR）客戶提供易受影響資產清單及相關建議。

主要措施包括：

一、優先升級至已修補的 Node.js 版本。

二、若應用程式不需要接受壓縮請求本文，可關閉相關解壓縮處理。

三、透過微分段限制受影響服務的存取範圍，並限制受影響主機的對外連線。

四、使用 Akamai Guardicore Segmentation 的查詢功能，協助找出可能受影響的主機。

Akamai 的應變顯示，重大漏洞處理不只涉及邊界流量防護，也需要掌握企業內部哪些系統使用受影響的執行環境，以及如何限制受影響主機的連線範圍。

對大型企業而言，即使已部署 CDN 或 WAF，仍須盤點內部應用程式與主機，避免因資產不明或內部連線過於寬鬆而擴大事件影響。

五、AWS：持續更新託管規則，降低客戶手動維護負擔

AWS 在 PHP2Shell 事件中，透過 AWS WAF PHP application Managed Rule Group 持續更新防護規則。

10 月 22 日：版本 2.3 新增 PHP2Shell_BODY 規則，針對 CVE-2026-109619 提供緩解。

10 月 23 日：版本 2.4 新增 PHP2Shell_BODY_Extended，補強對 CVE-2026-109618 的防護，並設為預設版本。

後續更新：AWS 也在公告中說明，版本 2.4 及後續版本的相關規則，可協助緩解另一項 CVE-2026-115560 的風險。這是額外披露的漏洞，並非原本兩項 PHP2Shell 漏洞的同一個 CVE。

AWS 表示，使用預設規則版本的客戶會自動取得更新；若固定使用特定舊版，則需要手動升級至較新的規則版本。

這種託管規則模式的價值，在於將部分防護維護工作交由服務供應商持續更新，降低客戶自行追蹤每一項漏洞與手動部署規則的負擔。

不過，AWS 也明確指出，WAF 規則屬於緩解措施，不能取代 PHP 正式修補。企業仍應優先更新受影響的執行環境，並依應用程式設定採取必要的主機端措施。

六、四家業者的應變方式有何差異？

從這些案例可以看出，重大漏洞應變並沒有單一適用所有環境的方式。不同服務可能著重於提前偵測、快速緩解、自動更新或內部資產盤點，而企業也需要依照自身架構選擇適當的措施。

七、企業遇到重大 RCE 漏洞時，應如何應變？

面對 PHP2Shell、Node2Shell 這類重大漏洞，建議企業依照以下方向處理。

1. 先盤點受影響的軟體與應用程式

確認網站、API、容器及相關服務使用的 PHP 或 Node.js 版本，並檢查是否存在已停止維護的版本。除了直接使用的執行環境，也應確認相依套件、框架與自動解壓縮流程是否可能受到影響。

2. 優先套用官方修補版本

正式更新仍是解決漏洞的首要措施。企業應依官方公告安排升級，並在部署前完成必要的相容性測試。對已停止維護的版本，則應評估遷移至受支援版本。

3. 在修補期間部署適當的緩解措施

若無法立即完成更新，可依服務供應商提供的規則或虛擬修補降低風險。但應確認規則是否涵蓋實際攻擊路徑，並留意部分漏洞可能無法單靠 HTTP 層的 WAF 規則完整防護。

4. 先觀察規則命中，再評估封鎖

當規則可能匹配正常請求時，可先採用 Log 或監控模式，檢查命中量與請求內容，再依實際環境調整封鎖條件。對 API、圖片服務及重要交易系統而言，這能降低緊急防護造成服務中斷的風險。

5. 檢查日誌與異常行為

除了部署防護規則，也應檢查網站與應用程式日誌，留意異常請求、非預期的程序執行、檔案變更及對外連線。若發現可能遭利用的跡象，應依企業事件應變流程進一步調查。

6. 建立持續更新與通知機制

重大漏洞可能在短時間內出現新的攻擊方式或相關漏洞公告。企業應建立漏洞情報追蹤、影響評估、規則更新、客戶通知與修補驗證流程，避免只在事件爆發時才開始處理。

八、SkyCloud 觀點：WAF 緩解、軟體修補與網站可用性必須並行

PHP2Shell 與 Node2Shell 顯示，當網站與應用程式使用的底層執行環境出現重大漏洞時，企業需要同時處理漏洞修補、網路防護與服務可用性等問題。

CDN 與 WAF 能協助管理進入網站的流量，依照規則偵測或緩解部分惡意請求；Anti-DDoS 則著重於降低大量網路攻擊流量對服務造成的影響。這些防護能力各有用途，不能互相取代，也無法取代受影響軟體的正式更新。

SkyCloud 騰雲運算提供 CDN、SkyWAF 與 Anti-DDoS 等網路效能及資安服務，協助企業改善內容傳輸、管理網站應用程式風險，並降低網路攻擊對服務可用性的影響。

面對重大漏洞，企業除了選擇合適的防護服務，也應確認緊急規則的適用範圍、更新時程、誤判處理方式與技術支援機制。透過邊界防護、主機修補、資產盤點與持續監控，才能更完整地降低漏洞遭利用的風險。

當重大漏洞發生時，真正有效的防護不只是快速部署一條規則，而是讓偵測、緩解、修補與持續監控形成完整的應變流程。