Die Forscher von Miggo entdeckten zwei Schwachstellen, die es Angreifern ermöglichen könnten, die Kontrolle über verwundbare Message-Broker zu übernehmen oder Daten in gemeinsam genutzten Umgebungen offenzulegen.
Zwar gibt es keine Belege dafür, dass eine der beiden Schwachstellen in freier Wildbahn ausgenutzt wurde, doch Unternehmen, die betroffene RabbitMQ-Versionen einsetzen, sollten die verfügbaren Patches vorrangig einspielen.
Wichtigste Erkenntnisse zu den RabbitMQ-Schwachstellen
- Zwei RabbitMQ-Schwachstellen könnten in betroffenen Umgebungen die Übernahme von Brokern ohne Authentifizierung ermöglichen oder Mandantenmetadaten offenlegen.
- CVE-2026-57219 ermöglicht es Angreifern, ein geheimes RabbitMQ-OAuth-Client-Geheimnis zu erlangen und möglicherweise administrative Kontrolle über verwundbare Broker zu gewinnen.
- CVE-2026-57221 umgeht Autorisierungsprüfungen und ermöglicht es authentifizierten Benutzern, Warteschlangen, Exchanges und Mandantenmetadaten aufzulisten.
Die RabbitMQ-Schwachstellen im Detail
RabbitMQ ist einer der weltweit am weitesten verbreiteten Open-Source-Message-Broker und bildet für viele Unternehmensanwendungen das Rückgrat der Nachrichtenübermittlung.
Es ermöglicht die Kommunikation zwischen verteilten Diensten, verarbeitet Zahlungstransaktionen, bearbeitet Authentifizierungsereignisse und unterstützt Cloud-native Anwendungen sowie Microservices.
Da RabbitMQ häufig im Zentrum geschäftskritischer Infrastrukturen steht, können Schwachstellen in der Plattform sensible Anwendungsdaten offenlegen und wichtige Geschäftsabläufe stören.
Die Forscher von Miggo identifizierten zwei Schwachstellen in der Zugriffskontrolle von RabbitMQ.
Eine ermöglicht es einem nicht authentifizierten Angreifer, das vertrauliche OAuth-Client-Geheimnis des Brokers zu erlangen, während die andere jedem authentifizierten Benutzer den Zugriff auf Metadaten anderer Mandanten ermöglicht, obwohl ihm dafür keine Berechtigungen erteilt wurden.
Beide Schwachstellen wurden Anfang 2024 in RabbitMQ 3.13.0 eingeführt und blieben im Code bestehen, bis Miggo sie entdeckte und verantwortungsvoll an die RabbitMQ-Maintainer meldete.
Zwar gibt es keine Belege dafür, dass eine der beiden Schwachstellen in freier Wildbahn ausgenutzt wurde, doch das Unternehmen empfiehlt Organisationen, die Behebung wegen der möglichen Auswirkungen auf Unternehmensumgebungen zu priorisieren.
CVE-2026-57219: Nicht authentifizierter OAuth-Geheimnisabfluss könnte vollständige Broker-Übernahme ermöglichen
CVE-2026-57219, mit einem CVSS-Score von 8,7, geht auf einen Fehler in der Autorisierung des veralteten RabbitMQ-Verwaltungsendpunkts /api/auth zurück.
Der Endpunkt gab das vertrauliche OAuth-Client-Geheimnis des Brokers zurück, ohne eine Authentifizierung zu verlangen, sodass jeder, der die Verwaltungsschnittstelle erreichen konnte, die Zugangsdaten mit einer einzigen Anfrage abrufen konnte.
Das Risiko ist für Unternehmen am größten, die RabbitMQ als vertraulichen OAuth-Client mit Identitätsanbietern wie Microsoft Entra ID, Auth0, Keycloak oder Cloud Foundry UAA einsetzen.
Ein Angreifer, der das offengelegte Client-Geheimnis erlangt, könnte es beim Identitätsanbieter gegen ein Zugriffstoken mit Administratorrechten eintauschen und sich damit effektiv als Broker ausgeben.
Eine erfolgreiche Ausnutzung könnte administrative Kontrolle über RabbitMQ ermöglichen, einschließlich seiner Benutzer, Warteschlangen, Exchanges, Nachrichten und Broker-Konfiguration.
Miggo führte das Problem auf eine Autorisierungsprüfung zurück, die Anfragen stets genehmigte, anstatt den Zugriff auf sensible Verwaltungsdaten zu beschränken.
CVE-2026-57221: Autorisierungsumgehung legt Mandantenmetadaten offen
Die zweite Schwachstelle, CVE-2026-57221, hat einen CVSS-Wert von 5,3 und betrifft die Funktion von RabbitMQ zum passiven Deklarieren von Warteschlangen und Exchanges.
Mit dieser Funktion können Clients überprüfen, ob eine Warteschlange oder ein Exchange vorhanden ist, ohne sie zu verändern. Miggo entdeckte jedoch, dass bei diesem Vorgang die Autorisierungsprüfungen fehlten, die von vergleichbaren RabbitMQ-Funktionen durchgesetzt werden.
Infolgedessen konnte jeder authentifizierte Benutzer – auch ein Konto ohne zugewiesene Berechtigungen – Warteschlangen und Exchanges auflisten und Metadaten wie Nachrichtenanzahl und Statistiken zu Verbrauchern abrufen.
Die Schwachstelle legt zwar keine Nachrichteninhalte offen und ermöglicht keine unbefugte Änderung von Daten, schwächt jedoch die Mandantenisolierung, indem sie Betriebsdetails zu anderen Anwendungen oder Benutzern offenlegt, die dieselbe RabbitMQ-Umgebung nutzen.
In mandantenfähigen Umgebungen könnten diese Informationen Angreifern dabei helfen, Anwendungsarchitekturen zu kartieren, besonders wertvolle Ziele zu identifizieren und Aufklärungsdaten für Folgeangriffe zu sammeln.
RabbitMQ-Risiken reduzieren
Unternehmen, die betroffene RabbitMQ-Versionen einsetzen, sollten die verfügbaren Patches einspielen und ihre Konfigurationen überprüfen, um potenzielle Risiken zu reduzieren.
- Aktualisieren Sie auf die neueste Version und wechseln Sie nach dem Patchen die OAuth-Client-Geheimnisse, wenn Ihre Bereitstellung vertrauliche OAuth-Clients verwendet.
- Wenn ein sofortiges Patchen nicht möglich ist, sollten Sie kompensierende Maßnahmen erwägen wie eine WAF-Regel, die bei CVE-2026-57219 den Zugriff auf den verwundbaren Endpunkt blockiert.
- Beschränken Sie den Zugriff auf die RabbitMQ-Verwaltungsschnittstelle durch Netzwerksegmentierung, VPNs, IP-Allowlists oder Zero Trust-Zugriffskontrollen, und setzen Sie sie niemals nicht vertrauenswürdigen Netzwerken aus.
- Überprüfen Sie RabbitMQ-Benutzer und Administratorkonten, virtuelle Hosts und Berechtigungen, um das Prinzip der geringsten Rechte durchzusetzen und Mandanten gegebenenfalls in dedizierten virtuellen Hosts zu isolieren.
- Überwachen Sie Protokolle der Verwaltungsschnittstelle und die Broker-Aktivität auf unbefugte API-Anfragen, unerwartete Administratorzugriffe, Konfigurationsänderungen oder ungewöhnliche Versuche, Warteschlangen aufzulisten.
- Testen Sie Pläne zur Reaktion auf Vorfälle mit Planspielen und Simulationstools, anhand von Szenarien zu Broker-Kompromittierungen oder unbefugtem Zugriff auf die Messaging-Infrastruktur.
Diese Maßnahmen können dazu beitragen, das Gesamtrisiko zu reduzieren, den Schadensradius einer Kompromittierung zu begrenzen und die Widerstandsfähigkeit zu stärken.
Fazit
Obwohl zum Zeitpunkt der Veröffentlichung keine der beiden Schwachstellen bei aktiven Angriffen beobachtet wurde, sollten Unternehmen ihre RabbitMQ-Bereitstellungen überprüfen, um betroffene Versionen und Konfigurationen zu ermitteln.
Außerdem sollten sie sicherstellen, dass die Verwaltungsschnittstellen ordnungsgemäß abgesichert sind und eingebettete oder paketierte RabbitMQ-Instanzen in die routinemäßigen Schwachstellenmanagementprozesse einbezogen werden.
Diese Überprüfungen können übersehene Infrastrukturen aufdecken, die andernfalls auch nach der Veröffentlichung von Upstream-Patches verwundbar bleiben könnten.
Während Unternehmen die Sicherheit von Plattformen wie RabbitMQ stärken, setzen viele außerdem auf Zero-Trust-Lösungen , um kritische Anwendungen und Infrastrukturen zu schützen.