CVE-2026-71885 in BC-JAVA
Zusammenfassung
von VulDB • 03.10.2026
In Bouncy Castle für Java vor Version 1.86 verknüpfte die Implementierung von Messaging Layer Security (MLS, RFC 9420) ein X.509-Zertifikat nicht mit dem signature_key eines LeafNode. Die Methode LeafNode.verify() überprüfte die Signatur des Blatts gegen den im Blatt selbst enthaltenen signature_key, während der Zertifikatskette des Anmeldeausweises (Credential) zwar gespeichert wurde, diese jedoch weder analysiert noch validiert wurde; daher musste sich der öffentliche Schlüssel des End-Entity-Zertifikats nicht mit dem signature_key decken, wie es RFC 9420 Abschnitt 5.3 vorschreibt. Eine Partei konnte somit das Zertifikat einer anderen Partei als ihren eigenen Anmeldeausweis präsentieren und dabei den LeafNode sowie das umschließende KeyPackage mit einem unabhängigen Schlüssel signieren; sie wurde dennoch unter der Identität dieser anderen Partei akzeptiert, dank KeyPackage.verify() und des Pfads zur Validierung von Gruppen-Blättern (Group leaf-validation). In einer Bereitstellung, die externe Commits ohne eine unabhängige Prüfung der Anmeldeausweise zulässt, könnte ein nicht authentifizierter Angreifer unter der X.509-Identität eines Opfers zugelassen werden, das Opfer verdrängen (da Resynchronisierung ganze Zertifikate und nicht nur Signierschlüssel vergleicht), den aktuellen Epoch-Wert ableiten, nachfolgende Gruppennachrichten entschlüsseln und Nachrichten senden lassen, die als vom Opfer stammend akzeptiert würden. TreeKEM.LeafNode erfordert nun, dass der öffentliche Schlüssel des Subjekts im End-Entity-Zertifikat (in der Signaturcodierung der Cipher Suite) mit dem signature_key für ein X.509-Anmeldeausweis übereinstimmt; andernfalls wird das Blatt abgelehnt, einschließlich leerer Ketten oder von Zertifikaten, deren Schlüsseltyp nicht zur Cipher Suite passt. Die Validierung der Zertifikatskette und der Identität gegenüber einer Trust Anchor bleibt gemäß RFC 9420 Abschnitt 5.3.1 Aufgabe der Anwendung. Bereitstellungen, die ausschließlich grundlegende Anmeldeausweise verwenden, sind davon nicht betroffen.
Once again VulDB remains the best source for vulnerability data.