RabbitMQ 爆兩個權限漏洞：先查 OAuth 設定，再升級兼換 secret
管理介面洩漏憑證同跨租戶資料探測，攻擊條件並唔一樣
RabbitMQ 今次兩個漏洞都同權限檢查有關，不過風險差好遠。CVE-2026-57219 喺特定設定下毋須登入就可攞走 OAuth client secret；CVE-2026-57221 就要攻擊者本身已有可連線帳戶，主要洩漏 queue、exchange 同工作量資料。 所以見到「毋須登入接管 RabbitMQ」呢類講法，唔可以直接套落所有部署。
先確認自己有冇中招
先喺每個節點執行 rabbitmq-diagnostics server_version，容器、Helm chart、代管映像同其他產品內置嘅 RabbitMQ 都要逐一查，唔好淨係望部署文件寫住咩版本。受影響範圍係 3.13.0 至 3.13.14、4.0.0 至 4.0.19、4.1.0 至 4.1.10，同 4.2.0 至 4.2.5。如果版本早過 3.13，呢兩份公告冇列入影響範圍，但嗰啲舊分支本身亦唔適合繼續拖住唔升。
跟住用 rabbitmq-plugins list -e 查 rabbitmq_management 同 rabbitmq_auth_backend_oauth2 有冇啟用，再檢查 rabbitmq.conf、advanced config、Kubernetes Secret 或部署平台注入嘅設定，睇下有冇 management.oauth_client_secret。處理設定輸出時要當佢係敏感資料，唔好貼入 ticket、聊天群組或一般 CI log。Management Plugin 預設常用 TCP port 係 15672，亦要由 load balancer、security group、防火牆同反向代理幾邊核對邊啲來源連得到。
CVE-2026-57219：四個條件要同時成立
官方公告講得幾清楚：部署要用受影響版本、啟用 Management Plugin、設定咗 management.oauth_client_secret，同埋攻擊者接觸到管理 HTTP API，先有機會經舊有 GET /api/auth endpoint 讀到 secret。冇用 OAuth 2、用其他 grant type、冇設定呢個 secret，或者根本冇開 Management Plugin，都唔屬於呢條漏洞嘅受影響配置。
Miggo 指出，攻擊者攞到 secret 後，喺身分供應商同權限設定配合嘅情況下，可以換取高權限 token，再控制 broker。呢條攻擊鏈嘅後半段受 OAuth grant、token claim 同 RabbitMQ 權限映射影響，唔代表漏出任何 client secret 都必然等於管理員權限。不過 secret 本身已經係長期憑證，如果管理介面曾經向唔可信網絡開放，就應該當佢已經外洩咁處理。
CVE-2026-57221：要有登入，但空權限帳戶都做到
第二條漏洞出現喺 AMQP 0-9-1 嘅 passive queue.declare 同 exchange.declare。官方公告確認，只要帳戶可連入某個 virtual host，即使 configure、write、read 權限全空，仍可猜測同確認 queue 或 exchange 名稱；queue 回應亦可帶出訊息數量同 consumer 數量。佢唔會直接讀走訊息內容、改寫 queue 或接管 broker，但共享 vhost 嘅多租戶環境會特別麻煩，因為工作量、命名方式同繁忙時間都可能俾低權限帳戶摸清。
呢條漏洞唔依賴 Management Plugin 或 15672 port，封住管理頁亦解決唔到。未完成升級之前，唔同信任級別嘅應用同租戶應分開 vhost，亦要覆核邊啲帳戶仍可建立 AMQP 連線。iThome 報道引述 Miggo 嘅研究，指暫時冇證據顯示兩個漏洞已喺真實攻擊中遭利用；呢點只代表未見到公開證據，唔適合當成延遲修補嘅理由。
修補次序：收窄入口、升級、再換 secret
官方列出嘅最低修補版本係 4.3.0、4.2.6、4.1.11、4.0.20 或 3.13.15。揀返現有分支可用嘅修補版，先喺 staging 核對 Erlang 相容性、feature flags、plugin 同叢集 rolling upgrade 路徑，再安排生產環境更新。由舊分支直上 4.3.0 唔一定可以一步完成；RabbitMQ 4.3 升級文件寫明，原地升級路徑由 4.2.x 開始，舊叢集要先按官方路徑過渡。
等升級期間，先把 15672 限制喺 VPN、管理 subnet、bastion host 或指定反向代理後面。CVE-2026-57219 亦可暫時停用 OAuth backend、改用唔靠 management.oauth_client_secret 嘅 grant type，或者停用 Management Plugin；呢啲做法要先評估登入同監察會唔會中斷。CVE-2026-57221 冇同等直接嘅網頁端封鎖方法，分拆 vhost 同盡快升級先係實際處理方法。
最後一步好多人會漏：完成修補後，去身分供應商產生新 OAuth client secret、更新 RabbitMQ 設定，再撤銷舊 secret。修補只會關掉洩漏入口，唔會令之前曝光嘅憑證自動失效。之後再查管理 API access log、反向代理紀錄、異常 token 簽發、權限變更同可疑 AMQP 連線；如果 15672 曾經向公網或其他租戶開放，就要由首次用受影響版本嗰日開始查。
參考來源
- iThome — 資安業者揭露RabbitMQ重大漏洞，可能導致OAuth金鑰外洩與訊息中介伺服器遭接管 — original report
- RabbitMQ 官方公告：CVE-2026-57219 — 核實 OAuth secret 洩漏所需配置、受影響版本、修補版本同暫時處理方法
- RabbitMQ 官方公告：CVE-2026-57221 — 核實 passive declare 權限繞過嘅攻擊條件、資料影響同修補版本
- RabbitMQ 官方版本資料 — 核對各分支版本、發布資料同支援狀況
- RabbitMQ 4.3.0 release notes — 核對升級至 4.3.0 嘅相容性、feature flags 同原地升級路徑
- Miggo 漏洞研究報告 — 漏洞發現者提供嘅攻擊鏈、配置條件同未見實際利用聲明；內容亦帶有自家研究系統宣傳
- NVD：CVE-2026-57219 — 交叉核對漏洞描述、CVSS 評分同 CISA 記錄嘅利用狀態
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
