CVE-2026-71891

Bouncy Castle for Java versiya 1.86-dək olan versiyalarda, BLS12_381BasicScheme.keyValidate və buna bağlı olaraq BLSPublicKeyParameters ilə hər bir BasicScheme, MessageAugmentation və ProofOfPossession funksiyalarının verify və aggregateVerify metodları, yalnız BLS12-381-in sahə xüsusiyyətini paylaşan kənar ECCurve əsasında qurulmuş açıq açarları qəbul edirdi. Sadə altqrup yoxlaması nöqtənin öz əyriyinin kofaktorunu təyin etməsinə güvənir, çünki əyrinin kofaktoru bir olduqda ECPoint.satisfiesOrder dərhal "true" qaytarır; beləliklə, fərqli tənliyə malik və kofaktoru süni şəkildə bir kimi göstərilmiş bir nöqtə, heç bir G1 nöqtəsi olmamasına baxmayaraq keyValidate yoxlamasından keçirdi. BC-nin pairing implementasiyasında belə bir nöqtə hədəf qrupda identikliyi təmin edir, buna görə də onu ehtiva edən açıq açarlar çoxluğu ilə yoxlanılan aqreqat imza, həmin açar və mesaj cütü üçün heç bir imza olmasa belə qəbul edilir ki, bu da "fantom imzalanan"ın (phantom signer) yaranmasına yol açır. Artıq keyValidate funksiyası hər hansı altqrup yoxlamasından əvvəl nöqtənin əyrisinin dəqiq kanonik G1 sahəsinə, tənliyinə, sırasına və kofaktoruna malik olduğunu təsdiqləyir. Bu problem yalnız tətbiqin aşkar, qeyri-kanonik əyridə ECPoint yaratdığı və onu səlahiyyətli açar kimi qəbul etdiyi hallarda mümkündür; standart 48 baytlıq sıxılmış nöqtə dekoderi həmişə kanonik əyrini təmin edir və bu problemdən təsirlənməyib.