Les chercheurs de Miggo ont découvert deux vulnérabilités qui pourraient permettre à des attaquants de prendre le contrôle de brokers de messages vulnérables ou d’exposer des données dans des environnements partagés.
Bien qu’aucune des deux vulnérabilités n’ait été exploitée dans la nature à ce jour, les organisations qui utilisent des versions concernées de RabbitMQ devraient donner la priorité à l’application des correctifs disponibles.
Principaux enseignements sur les vulnérabilités de RabbitMQ
- Deux vulnérabilités de RabbitMQ pourraient permettre de prendre le contrôle d’un broker sans authentification ou d’exposer les métadonnées des tenants dans les déploiements concernés.
- CVE-2026-57219 permet aux attaquants d’obtenir un secret client OAuth de RabbitMQ et potentiellement de prendre le contrôle administratif de brokers vulnérables.
- CVE-2026-57221 contourne les contrôles d’autorisation, permettant aux utilisateurs authentifiés d’énumérer les files d’attente, les exchanges et les métadonnées des tenants.
À propos des vulnérabilités de RabbitMQ
RabbitMQ est l’un des brokers de messages open source les plus déployés au monde et constitue l’épine dorsale de la messagerie de nombreuses applications d’entreprise.
Il permet la communication entre des services distribués, traite les transactions de paiement, gère les événements d’authentification et prend en charge les applications cloud natives et les microservices.
Comme RabbitMQ se trouve souvent au cœur d’infrastructures critiques pour l’activité, les vulnérabilités qui affectent la plateforme peuvent exposer des données applicatives sensibles et perturber des opérations essentielles.
Les chercheurs de Miggo ont identifié deux vulnérabilités de contrôle d’accès affectant RabbitMQ.
L’une permet à un attaquant non authentifié d’obtenir le secret client OAuth confidentiel du broker, tandis que l’autre permet à tout utilisateur authentifié de consulter les métadonnées appartenant à d’autres tenants malgré l’absence de toute autorisation.
Les deux vulnérabilités ont été introduites dans RabbitMQ 3.13.0 au début de 2024 et sont restées dans le code jusqu’à leur découverte par Miggo et leur signalement responsable aux mainteneurs de RabbitMQ.
Bien qu’aucune des deux failles n’ait été exploitée dans la nature à ce jour, l’entreprise recommande aux organisations de donner la priorité à la remédiation en raison de leur impact potentiel sur les environnements d’entreprise.
CVE-2026-57219 : une fuite de secret OAuth sans authentification pourrait permettre de prendre entièrement le contrôle du broker
CVE-2026-57219, avec un score CVSS de 8,7, découle d’une faille d’autorisation dans l’ancien endpoint de gestion /api/auth de RabbitMQ.
Cet endpoint renvoyait le secret client OAuth confidentiel du broker sans exiger d’authentification, permettant à toute personne pouvant atteindre l’interface de gestion de récupérer cet identifiant en une seule requête.
Le risque est particulièrement élevé pour les organisations qui utilisent RabbitMQ comme client OAuth confidentiel auprès de fournisseurs d’identité tels que Microsoft Entra ID, Auth0, Keycloak ou Cloud Foundry UAA.
Un attaquant qui obtient le secret client exposé pourrait l’échanger auprès du fournisseur d’identité contre un jeton d’accès administrateur, usurpant ainsi l’identité du broker.
Une exploitation réussie pourrait donner le contrôle administratif de RabbitMQ, notamment de ses utilisateurs, files d’attente, exchanges, messages et de sa configuration.
Miggo a attribué le problème à un contrôle d’autorisation qui approuvait toujours les requêtes au lieu de limiter l’accès aux données de gestion sensibles.
CVE-2026-57221 : un contournement de l’autorisation expose les métadonnées des tenants
La seconde vulnérabilité, CVE-2026-57221, affiche un score CVSS de 5,3 et affecte la fonctionnalité de déclaration passive des files d’attente et des exchanges de RabbitMQ.
Cette fonctionnalité permet aux clients de vérifier l’existence d’une file d’attente ou d’un exchange sans le modifier, mais Miggo a découvert que l’opération n’effectuait pas les contrôles d’autorisation appliqués par les fonctions comparables de RabbitMQ.
En conséquence, tout utilisateur authentifié — y compris un compte dépourvu d’autorisations — pouvait énumérer les files d’attente et les exchanges et récupérer des métadonnées telles que le nombre de messages et les statistiques des consommateurs.
Bien que la faille n’expose pas le contenu des messages et ne permette pas de modifier des données sans autorisation, elle affaiblit l’isolation entre tenants en révélant des informations opérationnelles sur d’autres applications ou utilisateurs partageant le même environnement RabbitMQ.
Dans les déploiements mutualisés, ces informations pourraient aider les attaquants à cartographier les architectures applicatives, à identifier des cibles de grande valeur et à effectuer des reconnaissances en vue d’attaques ultérieures.
Réduire les risques liés à RabbitMQ
Les organisations qui utilisent des versions concernées de RabbitMQ devraient appliquer les correctifs disponibles et revoir leur configuration afin de réduire les risques potentiels.
- Mettez à jour vers la dernière version et renouvelez les secrets clients OAuth après l’application du correctif si votre déploiement utilise des clients OAuth confidentiels.
- Si l’application immédiate des correctifs n’est pas possible, envisagez des mesures compensatoires telles qu’une règle WAF bloquant l’accès à l’endpoint vulnérable pour CVE-2026-57219.
- Limitez l’accès à l’interface de gestion de RabbitMQ à l’aide d’une segmentation réseau, de VPN, de listes d’adresses IP autorisées ou de contrôles d’accès Zero Trust, et ne l’exposez jamais à des réseaux non fiables.
- Examinez les utilisateurs RabbitMQ et les comptes administrateurs, les hôtes virtuels et les autorisations afin d’appliquer le principe du moindre privilège et d’isoler les tenants dans des hôtes virtuels dédiés lorsque cela est approprié.
- Surveillez les journaux de l’interface de gestion et l’activité du broker afin de détecter les requêtes API non autorisées, les accès administrateur inattendus, les modifications de configuration ou les tentatives inhabituelles d’énumération des files d’attente.
- Testez les plans de réponse aux incidents au moyen d’exercices sur table et d’outils de simulation, en envisageant des scénarios de compromission du broker ou d’accès non autorisé à l’infrastructure de messagerie.
Ces mesures peuvent contribuer à réduire le risque global, à limiter le périmètre d’une compromission et à renforcer la résilience.
En résumé
Bien qu’aucune des deux vulnérabilités n’ait été observée dans le cadre d’attaques actives au moment de la publication, les organisations devraient examiner leurs déploiements RabbitMQ afin d’identifier les versions et configurations concernées.
Elles devraient également confirmer que les interfaces de gestion sont correctement sécurisées et que les instances RabbitMQ intégrées ou déployées sous forme de packages sont incluses dans les processus réguliers de gestion des vulnérabilités.
Ces examens peuvent aider à repérer des infrastructures négligées qui pourraient rester vulnérables après la publication des correctifs en amont.
Alors que les organisations renforcent la sécurité de plateformes telles que RabbitMQ, nombre d’entre elles adoptent également des solutions Zero Trust pour contribuer à protéger les applications et infrastructures critiques.