這是一篇針對 WordPress 核心（Core）最近發現的嚴重安全性漏洞 wp2shell 的技術解析。對於維護網站的工程師來說，最重要的一點是：這個漏洞不需要任何權限，也不需要安裝任何外掛，只要版本符合，攻擊者就能直接接管你的伺服器。
漏洞背景與影響範圍
這次被命名為 wp2shell 的漏洞存在於 WordPress 的核心程式碼中，而非第三方外掛。這意味著即便你安裝的是最乾淨的預設版本，依然處於風險之中。
受影響的版本範圍包括 6.9.0 至 6.9.4 以及 7.0.0 至 7.0.1。官方已透過發佈 6.9.5 與 7.0.2 版本來修復此問題。值得注意的是，WordPress 此次採取了強制更新（Forced Updates）機制，試圖讓更多網站快速修復，但如果你在設定中關閉了自動更新，仍需手動檢查版本。
技術原理：從 API 混淆到 RCE
這個漏洞的成因相當複雜，它結合了兩個關鍵的安全性問題：REST API 批次路由混淆（REST API batch-route confusion）以及 SQL 注入（SQL Injection）。
首先，我們要了解 REST API 批次端點（Batch Endpoint）。這是 WordPress 提供的一個功能，允許開發者在一次 HTTP 請求中發送多個 API 呼叫，以減少網路往返時間。
漏洞發生在 6.9 版本之後。攻擊者利用批次路由的處理邏輯漏洞，造成系統對請求路徑的認知產生混淆。這種混淆讓攻擊者能夠繞過原有的權限檢查，將惡意的 SQL 指令注入到資料庫查詢中。
在 Web 安全中，SQL 注入通常只能用來竊取資料，但當它發生在特定的核心函數且能控制執行流程時，就可能演變成遠端程式碼執行（Remote Code Execution, RCE）。RCE 是最危險的漏洞等級，因為它允許攻擊者在伺服器上執行任意指令，例如安裝後門、刪除資料庫或將伺服器變成殭屍網路的一員。
實務上的風險與偵測困難
目前這個漏洞面臨一個特殊的管理問題：它在發佈初期沒有對應的 CVE 編號（CVE 是全球統一的漏洞識別碼）。
對企業安全團隊來說，這是一個巨大的挑戰。大多數的安全掃描器或資產管理工具是依賴 CVE 編號來標記風險的。如果沒有 CVE，自動化工具將無法提醒你網站正處於危險之中。因此，目前唯一的可靠確認方式是直接檢查 WordPress 的版本號。
為什麼開源軟體容易被快速利用
這涉及到開源軟體的悖論。當 WordPress 發佈修復版本（例如從 7.0.1 升級到 7.0.2）時，由於原始碼是公開的，攻擊者只需要對比這兩個版本的差異（Diff），就能迅速推導出漏洞的位置以及如何觸發它。
這就是為什麼在漏洞公開後，與時間的競賽就開始了。攻擊者會迅速開發出自動化腳本，大規模掃描全網尚未更新的 WordPress 網站。
緊急緩解方案
如果你因為某些原因無法立即更新版本，可以採取以下臨時措施來阻斷攻擊路徑。其核心邏輯是：禁止匿名使用者存取批次端點（Batch Endpoint）。
第一種方式是透過 WAF（網頁應用程式防火牆）封鎖請求。請注意，必須同時封鎖 /wp-json/batch/v1 路徑以及包含 rest_route=/batch/v1 的查詢字串，因為攻擊者可以透過不同的路徑格式來繞過單一的封鎖規則。
第二種方式是直接禁用 WordPress REST API 的匿名存取權限。雖然這最安全，但可能會導致依賴 API 的合法第三方整合功能失效。
第三種方式是撰寫一個簡單的 Drop-in 外掛，在 rest_pre_dispatch 階段攔截並拒絕所有針對 /batch/v1 的匿名請求。
總結與建議
對於工程師而言，面對這類核心漏洞，最穩健的策略永遠是保持版本更新。不要假設自動更新一定成功，應建立版本追蹤機制。在面對沒有 CVE 編號的零日漏洞時，關注官方版本公告比依賴掃描工具更為重要。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。