CVE-2026-71885

W Bouncy Castle dla języka Java przed wersją 1.86 implementacja Messaging Layer Security (MLS, RFC 9420) nie wiązała poświadczeń X.509 z kluczem podpisu LeafNode. Funkcja LeafNode.verify() sprawdzała podpis liścia pod kątem podpisu_klucza znajdującego się w samym liściu, podczas gdy łańcuch certyfikatów X.509 poświadczenia był przechowywany, ale nigdy nie był analizowany ani sprawdzany, więc klucz publiczny certyfikatu jednostki końcowej nigdy nie był wymagany do dopasowania klucz_podpisu zgodnie z RFC 9420 sek. 5.3 wymaga. Strona może zatem przedstawić certyfikat innej strony jako swoje poświadczenie podczas podpisywania liścia oraz załączony pakiet KeyPackage z niepowiązanym kluczem i zostać zaakceptowana pod tożsamością tej drugiej strony poprzez KeyPackage.verify() i ścieżkę walidacji liścia grupy. W przypadku wdrożenia, które dopuszcza zewnętrzne zatwierdzenia bez niezależnej kontroli dostępu do poświadczeń, nieuwierzytelniony atakujący może zostać wpuszczony pod tożsamość X.509 ofiary, eksmitować ofiarę (resynchronizacja porównuje całe poświadczenia, a nie podpisywanie kluczy), uzyskać bieżącą epokę, odszyfrować kolejne wiadomości grupowe i wysłać wiadomości zaakceptowane jako ofiara. TreeKEM.LeafNode wymaga teraz, aby klucz publiczny podmiotu certyfikatu jednostki końcowej, w kodowaniu podpisu zestawu szyfrów, był równy kluczowi podpisu dla poświadczeń X.509 i w przeciwnym razie odrzuca liść, w tym pusty łańcuch lub certyfikat, którego typ klucza nie pasuje do zestawu szyfrów; weryfikacja łańcucha certyfikatów i tożsamości w kotwicy zaufania pozostaje obowiązkiem aplikacji zgodnie z RFC 9420 ust. 5.3.1. Nie ma to wpływu na wdrożenia wykorzystujące tylko podstawowe poświadczenia.