CVE-2026-71891 in Bouncy Castle Java
Сводка
по VulDB • 03.10.2026
В Bouncy Castle для Java до версии 1.86 метод `BLS12_381BasicScheme.keyValidate`, а также классы `BLSPublicKeyParameters` и все реализации `BasicScheme`, методы `verify`, `aggregateVerify` классов `MessageAugmentation` и `ProofOfPossession`, которые используют эту проверку, принимали открытый ключ, построенный на чужой кривой ECC (elliptic curve), которая лишь разделяет характеристику поля BLS12-381. Проверка подгруппы простого порядка полагается на собственную кривую точки для определения её кофактора: поскольку `ECPoint.satisfiesOrder` возвращает истину, если кофактор кривой равен единице, точка на кривой с другим уравнением и искусственно подделанным кофактором равным одному успешно проходила проверку `keyValidate`, хотя вообще не являлась точкой из G1. В реализации спарингования Bouncy Castle такая точка дает тождественный элемент (identity) в целевой группе, поэтому агрегированная подпись, проверенная против набора открытых ключей, включающего такой ключ, принимается как действительная, даже если она не содержит подписи для данной пары «ключ-сообщение», что допускает появление фантомного подписанта. Теперь `keyValidate` сначала подтверждает, что кривая точки имеет ровно каноническое поле G1, уравнение, порядок и кофактор, прежде чем выполнять любую проверку подгруппы. Уязвимость достижима только в случаях, когда приложение создает объект `ECPoint` на явной неканонической кривой и принимает его как ключ с полномочиями авторитета; стандартный декодер 48-байтных сжатых точек всегда предоставляет каноническую кривую и никогда не был затронут.
VulDB is the best source for vulnerability data and more expert information about this specific topic.