近期安全研究人員揭露了 RabbitMQ 訊息代理服務中兩個嚴重的存取控制漏洞。這兩個漏洞主要影響 RabbitMQ 3.13.0 之後的版本，如果未及時更新，可能會導致攻擊者接管整個訊息代理伺服器，或是竊取其他租戶的機密資訊。
對於負責維運的工程師來說，理解這類漏洞的核心在於「權限邊界」的崩潰。RabbitMQ 是一個處理大量企業數據的中間件，其安全基石在於確保不同使用者或租戶之間不能互相干擾。而這次的漏洞正好擊中了這兩個關鍵點。
第一個高風險漏洞：OAuth 客戶端金鑰洩漏
漏洞編號為 CVE-2026-57219，其 CVSS 評分高達 8.7。這個問題出在一個被遺忘的舊版 HTTP API 接口 GET /api/auth 上。
在許多企業環境中，為了實現單一登入或標準化認證，會配置 OAuth 2.0 協議。OAuth 是一種開放標準的授權框架，允許應用程式在不直接獲取使用者密碼的情況下獲得有限的存取權限。而管理這個過程的核心是 Client Secret，也就是客戶端金鑰，它相當於該應用程式的密碼。
由於這個 API 接口缺乏正確的驗證機制，任何未經認證的攻擊者只要發送單次請求，就能直接獲取 RabbitMQ 伺服器配置的 OAuth Client Secret。一旦拿到這把金鑰，攻擊者可以偽造身分請求管理員權限的 Token，進而取得對整個 RabbitMQ 叢集的最高控制權，包括讀取所有訊息、刪除隊列或修改系統設定。
第二個中風險漏洞：跨租戶元數據暴露
漏洞編號為 CVE-2026-57221，CVSS 評分 5.3。這個漏洞涉及的是 RabbitMQ 的多租戶隔離機制。
在 RabbitMQ 中，Virtual Host（虛擬主機，簡稱 vhost）是用來將單一 RabbitMQ 實例邏輯上劃分為多個獨立環境的機制，類似於虛擬主機或命名空間，用來確保不同專案或客戶的數據互不干擾。
然而，研究人員發現某個管理接口的授權檢查被錯誤地硬編碼為永遠允許請求。這意味著任何只要能登入並連接到該 vhost 的合法使用者，即使他沒有權限查看其他隊列，依然可以靜默地列出該 vhost 內所有的隊列名稱、交換機名稱，以及查看訊息數量和消費者數量。雖然這不能直接讓攻擊者讀取訊息內容，但暴露的元數據（Metadata，即描述數據的數據）能讓攻擊者掌握系統架構，為後續的針對性攻擊提供情報。
實務影響與風險場景
這類漏洞在雲端環境或多租戶部署中風險最高。如果你的 RabbitMQ 管理介面（預設連接埠 15672）直接暴露在公網，或者處於一個不可信的內部網路中，攻擊者可以輕易地利用這些 API 漏洞進行滲透。
除了上述兩個漏洞，RabbitMQ 最近還修復了兩個極高風險的 TLS 客戶端認證繞過漏洞。這顯示出在處理身份驗證與加密傳輸時，任何微小的實作錯誤都可能導致整個安全鏈條崩潰。
修復建議與防禦對策
首先，最直接的解決方案是將 RabbitMQ 更新至安全版本，包括 4.3.0, 4.2.6, 4.1.11, 4.0.20 或 3.13.15 及以上版本。
其次，對於已經更新的系統，如果之前的管理介面曾暴露在網際網路上，強烈建議立即輪轉（Rotate）OAuth Client Secret，因為金鑰可能在不知情的情況下已被竊取。
在基礎設施層面，應採取深度防禦策略。首先，限制 15672 管理連接埠的存取，僅允許受信任的 IP 或透過 VPN 存取，避免管理介面直接對外開放。其次，嚴格執行 vhost 的隔離策略，並在防火牆層級封鎖可疑的 API 路徑。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。