WordPress 已更新到最新核心，仍不代表主機的 Brotli 漏洞已修好。Wordfence 在 2026 年 11 月 2 日發布研究，說明 WordPress 的 XML-RPC pingback 如何讓外部壓縮回應進入主機解碼器，並在特定隔離環境重現程式碼執行。這是 CVE-2026-111497 的 WordPress 風險說明，不是另一個新漏洞。
要核對的是網站程序載入的函式庫
這條路徑由 WordPress 向外取得資料，受影響的 HTTP client 再解壓 Brotli 回應。風險不只在訪客送進網站的內容，主機向外取得的資料也可能進入解碼器。只更新 WordPress、外掛或主題，不會自動替換作業系統、容器或 PHP 環境附帶的 Brotli。
上游對應修補版本是 1.0.10、1.1.1 與 1.2.1。Linux 發行版可能保留主版本並回移修補，例如 Debian 13 的安全套件為 1.1.0-2+deb13u1。請主機商核對完整套件修訂及網站實際載入的副本，再重新啟動或部署相關程序；只看前三段版本號可能誤判。
停用 XML-RPC 驗證，不等於停用 pingback
示範路徑需要 XML-RPC 可達、pingback.ping 方法可用、目標文章允許 ping、主機能外連，以及 HTTP client 使用受影響解碼器。單憑網站有 xmlrpc.php，無法判定一定可以利用；同樣，封住這條入口也不會修復函式庫。
WordPress 官方文件明確說明，xmlrpc_enabled 只控制需要驗證的方法，並不控制匿名 pingback。設定名稱看起來像「停用 XML-RPC」，也應核對實際停用範圍。「設定 → 討論」的新文章預設值亦不會自動改掉所有舊文章的 ping 設定。
先完成主機更新，再判斷是否需要調查
可直接請維護者提供三項資料：網站使用的 Brotli 副本與修補依據、相關程序重新載入的時間，以及其他 PHP pool／容器是否也已處理。容器應從更新後的基礎映像重新建置，單純重啟舊容器不會換掉裡面的套件。
Wordfence 的實驗結果依賴特定伺服器配置，不能推成所有 WordPress 站都會被同一請求接管，也不能把實驗成功當作正式網站已遭入侵。若先前長時間未修補，應保留外連、PHP 錯誤與程序重啟紀錄供維護者調查；不必在正式站執行公開攻擊程式來確認版本。
資料核對日期：2026 年 11 月 3 日。封面為 AI 生成的風險概念插畫。
