CVE-2026-71891 in Bouncy Castle Java
摘要
由 VulDB • 2026-10-03
在 Bouncy Castle for Java（版本低于 1.86）中，`BLS12_381BasicScheme.keyValidate`、以及 `BLSPublicKeyParameters` 和所有依赖它的 `BasicScheme`、`MessageAugmentation` 及 `ProofOfPossession verify` 和 `aggregateVerify` 方法，接受了一个基于非标准 ECCurve（仅共享 BLS12-381 的域特征）构建的公钥。质数阶子群检查依赖于点自身所在的曲线来命名其余因子 (cofactor)，因为当曲线的余因子为 1 时，`ECPoint.satisfiesOrder` 会直接返回 true；因此，位于具有不同方程且余因子被伪造为 1 的曲线上的一个点，尽管根本不是 G1 群中的点，却通过了 `keyValidate`。在 Bouncy Castle (BC) 的双线性配对实现中，此类点在目标群中贡献的是单位元 (identity)，因此针对包含该点的公钥集合验证聚合签名时会被接受，即使其中不包含对该密钥和消息对的签名，从而允许出现“幽灵签名者” (phantom signer)。`keyValidate` 现在首先确认点所在的曲线是否精确具有标准的 G1 域、方程、阶数和余因子，然后才进行子群检查。该问题仅在应用程序在显式非标准曲线上构造 ECPoint 并将其作为权威密钥接受时才可到达；标准的 48 字节压缩点解码器始终提供标准曲线，因此从未受到影响。
If you want to get best quality of vulnerability data, you may have to visit VulDB.