Présentation de la vulnérabilité
Le projet Bouncy Castle, bibliothèque cryptographique Java largement intégrée dans les applications serveur et mobiles, a publié le CVE-2026-71885. Cette faille concerne toutes les versions antérieures à la 1.86. Elle résulte d’une validation de certificat inadéquate dans l’implémentation du protocole Messaging Layer Security (MLS). En pratique, un acteur malveillant peut présenter des certificats arbitraires, se faire reconnaître comme un participant légitime et intercepter les messages chiffrés au sein d’un groupe MLS.
Mécanisme d’exploitation
Le protocole MLS repose sur un « cryptographic binding » entre le certificat d’entité finale et la clé de signature du nœud feuille (LeafNode). Dans les versions affectées, le code ne vérifie pas que le certificat présenté correspond à la clé publique utilisée pour signer les messages. Un attaquant peut donc générer un certificat factice, l’associer à une clé contrôlée, puis injecter ce certificat dans le processus d’établissement de session. Le serveur accepte alors le certificat sans détecter la divergence, ce qui permet de spoof un participant et de déchiffrer les flux chiffrés grâce à la connaissance de la clé privée factice. La faille ne nécessite aucune authentification préalable, ce qui la rend exploitable à distance dès que le service expose une interface MLS.
Conséquences et mesures d’atténuation
Les systèmes qui utilisent Bouncy Castle pour sécuriser les communications inter‑services – notamment les plateformes de messagerie d’entreprise, les services IoT et certaines applications bancaires – sont exposés à la compromission de la confidentialité et de l’intégrité des échanges. La portée dépend du nombre de groupes MLS déployés et du niveau de sensibilité des données transitant dans ces groupes. Aucun incident d’exploitation publique n’a été signalé à ce jour, mais la nature de la faille autorise une attaque passive de décryptage ainsi qu’une usurpation active de participants.
Le correctif consiste à mettre à jour la bibliothèque vers la version 1.86 ou supérieure, où la validation du certificat a été renforcée et le binding cryptographique correctement appliqué. Les équipes de développement doivent recompiler leurs applications avec la version corrigée, vérifier que les dépendances transitives utilisent également la version mise à jour, et, si possible, activer des contrôles supplémentaires de cohérence entre certificat et clé publique au niveau de l’application. Dans les environnements où la mise à jour immédiate n’est pas réalisable, il est recommandé de désactiver les fonctionnalités MLS ou d’isoler les services concernés derrière des contrôles d’accès réseau stricts afin de limiter l’exposition.
