RabbitMQ sous la menace: deux défaillances de contrôle d'accès exposent les secrets OAuth et vous permettent de prendre le contrôle du courtier

Les chercheurs en sécurité de Miggo ont découvert et signalé deux défaillances de contrôle d'accès dans RabbitMQ qui affectent les versions de la ligne 3.13.0 et qui, ensemble, peuvent mettre en danger la confidentialité et l'isolement des locataires de l'infrastructure de messagerie commerciale. Une des défaillances permet à un attaquant non authentifié de récupérer le secret OAuth du courtier, qui dans les paramètres configurés pour utiliser ce secret peut entraîner l'obtention du jeton d'un administrateur et, par conséquent, le contrôle total sur les queues, les messages, les utilisateurs et la configuration du courtier. L'autre défaut permet à tout utilisateur authentifié de lister les files d'attente et les échanges dans un hôte étranger virtuel et de consulter les compteurs de messages et les consommateurs sans respecter les autorisations.

La présence d'un paramètre HTTP obsolète et accessible qui renvoie des informations sensibles met en évidence une défaillance classique : une voie administrative qui n'applique pas la même autorisation que d'autres points critiques. L'exposition d'un OAuth secret est particulièrement grave parce qu'il transforme une fuite d'information en une pleine capacité d'attaque en échangeant le secret pour des références valides. Dans les environnements multi-tenus, dans les nuages publics ou lorsque l'interface de gestion (par défaut dans le port 15672) est accessible à partir de réseaux peu fiables, le risque est multiplié.

RabbitMQ a publié des corrections dans les branches 4.3.0, 4.2.6, 4.1.11, 4.0.20 et 3.1.15 pour résoudre ces problèmes, et les responsables ont simultanément traité d'autres vulnérabilités critiques liées à l'authentification TLS et à la validation JWKS qui pourraient permettre aux JWT d'être acceptés par un attaquant AitM. Il est essentiel d'examiner et de mettre en œuvre les mises à jour officielles; la page de sécurité et les notes de version du projet sont le point de départ pour la vérification des versions et des correctifs: https: / / www.rabbitmq.com / security.html et la documentation du plugin de gestion décrivant le port et les terminaux concernés: https: / / www.rabbitmq.com / management.html.

S'il n'est pas possible de stationner immédiatement, des mesures d'atténuation urgentes réduisent la fenêtre d'exposition. Rotation du secret OAuth associé à la direction. oauth _ client _ secret dans toute installation dont l'interface de gestion est accessible à partir de réseaux peu fiables; un secret commis doit être invalidé de manière préventive. Limiter l'accès à l'interface de gestion (port 15672) par les règles de pare-feu ou la segmentation du réseau, et envisager de bloquer spécifiquement la route vulnérable (par exemple les règles WAF qui refusent GET / api / auth) jusqu'à ce que le patch soit appliqué. Séparer les clients par des hôtes virtuels et appliquer des contrôles d'accès stricts par des hôtes virtuels pour contenir la surface affectée.

En plus des mesures d'atténuation techniques, il est recommandé de vérifier les registres et de rechercher des signes d'abus : délivrance de jetons administratifs inhabituels, connexions des adresses IP externes à la gamme habituelle et opérations administratives imprévues dans les files d'attente et les échanges. Si une activité suspecte est détectée, procéder à la révocation des titres de compétence touchés, à la rotation des secrets et, si nécessaire, à la restauration des sauvegardes effectuées avant l'intrusion. Pour en savoir plus sur les entrées et la gravité de la CVE, consultez la base de données sur la vulnérabilité du NIST : CVE-2026-57219 et CVE-2026-57221.

Du point de vue du risque opérationnel, ces défaillances se rappellent que les courtiers de messagerie ne sont pas seulement des composantes de transit de données : contenir des métadonnées et des références qui, si elles sont exposées, permettent des mouvements latéraux et un contrôle persistant dans l'infrastructure. Les équipes de développement et d'exploitation devraient traiter les interfaces de gestion avec la même rigueur que les API exposées par le public : authentification forte, autorisation cohérente dans tous les paramètres et minimisation du rayon d'explosion par segmentation et principes moins privilégiés.

Pour les gestionnaires qui gèrent le cloud ou les environnements multi-locataires, la combinaison d'erreurs - la fuite du secret et la lecture de l'information entre locataires - est particulièrement inquiétante car elle facilite l'escalade de l'accès légitime à un locataire à la prise de contrôle de l'ensemble du courtier. Examiner les politiques d'accès au réseau, appliquer des contrôles d'authentification mutuels (mTLS) le cas échéant, et surveiller les réponses JWKS et les paramètres de certificat après avoir appliqué des mises à jour pour corriger les vulnérabilités TLS/JWKS nouvellement signalées.

Enfin, maintenir une mise à jour des tests de cadence et de sécurité : intégrer des analyses administratives dans les évaluations régulières, effectuer des tests de pénétration axés sur la gestion du courtier et documenter les procédures de réponse pour la rotation des secrets et la restauration après engagement. La combinaison de modifications immédiates, temporaires et organisationnelles de la façon dont les interfaces administratives sont exposées et protégées réduira considérablement la probabilité de vulnérabilités telles que celles-ci entraînant des incidents graves.