Deux failles dans RabbitMQ transforment une simple requête HTTP en fuite de secrets OAuth. Le célèbre broker de messages open source vient de colmater deux vulnérabilités qui pèsent lourd sur les déploiements multi-tenant. La première peut aller jusqu’à offrir la prise de contrôle complète du broker sur un plateau.
Points clés
- CVE-2026-57219 : l’endpoint GET /api/auth pouvait divulguer le client secret OAuth 2 à un appelant non authentifié, ouvrant la voie à une prise de contrôle du broker.
- CVE-2026-57221 : les déclarations passives de queues et exchanges exposaient des métadonnées (nombre de messages, consommateurs) à des utilisateurs sans permissions.
- Versions corrigées : 3.13.15, 4.0.20, 4.1.11 et 4.2.6 ; failles présentes depuis la branche 3.13.0 de début 2024.
- Recommandations : mettre à jour, faire tourner les secrets OAuth exposés et isoler l’interface de management des réseaux non fiables.
Une fuite de secret via un vieux point d’API
La vulnérabilité CVE-2026-57219 a été corrigée dans les branches 3.13, 4.0, 4.1 et 4.2. Le coupable ? Un ancien endpoint de management, GET /api/auth, qui pouvait renvoyer le client secret OAuth 2 à un appelant non authentifié dès lors que le plugin de management et une certaine configuration OAuth étaient activés. Un secret censé rester secret, distribué à qui le demande poliment.
D’après les relais spécialisés en sécurité, la faille touche les versions antérieures à 3.13.15, 4.0.20, 4.1.11 et 4.2.6. Le correctif supprime purement et simplement ce point d’accès obsolète au profit d’un mécanisme de bootstrap authentifié.
Le risque dépend du déploiement. Dans les installations qui utilisent des clients OAuth confidentiels avec des fournisseurs comme Microsoft Entra ID, Auth0, Keycloak ou UAA, le vol du secret permet d’obtenir un jeton administrateur et de s’emparer du broker.
Une seconde faille pour cartographier queues et exchanges
La deuxième vulnérabilité, CVE-2026-57221, vise les opérations passives de déclaration de queues et d’exchanges. RabbitMQ ne vérifiait pas les autorisations sur les commandes queue.declare et exchange.declare en mode passif. Résultat : un utilisateur authentifié mais sans permissions pouvait deviner l’existence d’objets et en lire certaines métadonnées.
Les données exposées incluent le nombre de messages et le nombre de consommateurs actifs. Pas d’accès au contenu des messages ni de possibilité de les modifier, rassurons-nous. Mais dans un environnement partagé, cela suffit à espionner l’activité des autres locataires du même virtual host.
Là encore, les versions corrigées sont 3.13.15, 4.0.20, 4.1.11 et 4.2.6. Les chercheurs préviennent qu’aucun pare-feu applicatif ne bloque cette faille : la seule parade est la mise à jour, avec en attendant une séparation stricte des tenants dans des virtual hosts distincts.
Des versions vulnérables depuis 3.13.0
Les deux failles remontent à la branche 3.13.0, introduite début 2024. RabbitMQ étant un broker open source largement utilisé pour le messaging et le streaming, ces correctifs concernent directement les équipes qui l’utilisent pour des applications internes, des systèmes distribués ou des plateformes multi-tenant.
Miggo Security indique avoir découvert les vulnérabilités via sa plateforme autonome de recherche VulnHunter, puis les avoir validées avec son équipe de sécurité avant divulgation aux mainteneurs de RabbitMQ.
La consigne des équipes qui ont documenté la prise de contrôle complète du broker tient en trois points : appliquer les mises à jour, faire tourner les secrets OAuth potentiellement exposés et surtout ne jamais exposer l’interface de management à des réseaux non fiables. Un rappel qu’un endpoint oublié coûte parfois tout un cluster.
