CVE-2026-71885

Bouncy Castle for Java 1.86 öncesi sürümlerde, Messaging Layer Security (MLS, RFC 9420) uygulaması bir X.509 kimlik bilgisini bir LeafNode'un signature_key değerine bağlamıyordu. LeafNode.verify(), bir yaprağın imzasını yaprağın kendisinde taşıdığı signature_key ile kontrol ediyordu; ancak kimlik bilgisinin X.509 sertifika zinciri saklanıyor fakat hiçbir zaman ayrıştırılmıyor veya doğrulanmıyordu, bu nedenle uç varlık sertifikasının genel anahtarının RFC 9420 bölüm 5.3'te gerektirdiği gibi signature_key ile eşleşmesi hiçbir zaman zorunlu kılınmadı. Bu durum, bir tarafın yaprağı ve onu kapsayan KeyPackage'ı ilgisiz bir anahtarla imzalarken başka bir tarafın sertifikasını kendi kimlik bilgisi olarak sunabilmesine ve KeyPackage.verify() ile Grup yaprak doğrulama yolu üzerinden diğer tarafın kimliğiyle kabul edilmesine olanak tanıyordu. Bağımsız bir kimlik bilgisi kabul kontrolü olmadan harici commit'lere izin veren bir dağıtımda, kimliği doğrulanmamış bir saldırgan kurbanın X.509 kimliği altında kabul edilebilir, kurbanı sistemden çıkarabilir (yeniden senkronizasyon imza anahtarları yerine tüm kimlik bilgilerini karşılaştırır), mevcut epoch'u türetebilir, sonraki grup mesajlarını çözebilir ve kurban olarak kabul edilen mesajlar gönderebilirdi. TreeKEM.LeafNode artık bir X.509 kimlik bilgisi için şifre paketinin imza kodlamasındaki uç varlık sertifikasının konu genel anahtarının signature_key değerine eşit olmasını şart koşmakta ve boş bir zincir veya anahtar türü şifre paketiyle eşleşmeyen bir sertifika da dahil olmak üzere aksi durumlarda yaprağı reddetmektedir; güven çapasına yönelik sertifika zinciri ve kimlik doğrulaması, RFC 9420 bölüm 5.3.1 uyarınca uygulamanın sorumluluğunda kalmaya devam etmektedir. Yalnızca temel kimlik bilgilerini kullanan dağıtımlar etkilenmemiştir.