CVE-2026-71885 in BC-JAVA
摘要
由 VulDB • 2026-10-03
在 Bouncy Castle for Java 1.86 之前的版本中，Messaging Layer Security (MLS, RFC 9420) 的实现未将 X.509 凭据绑定到 LeafNode 的 signature_key。LeafNode.verify() 检查叶节点的签名是否与其自身携带的 signature_key 匹配，而凭据中的 X.509 证书链虽被存储但从未解析或验证，因此最终实体证书的公钥无需如 RFC 9420 第 5.3 节所要求的那样与 signature_key 一致。因此，攻击者可以出示另一方的证书作为其凭据，同时使用无关密钥对叶节点及包含它的 KeyPackage 进行签名，并通过 KeyPackage.verify() 和 Group leaf-validation 路径被接受为该其他方身份。在允许外部提交（external commits）且缺乏独立凭据准入检查的部署中，未认证的攻击者可以冒充受害者的 X.509 身份加入群组，驱逐受害者（resynchronization 比较的是完整凭据而非签名密钥），推导当前 epoch，解密后续组消息，并发送被接受为来自受害者的消息。TreeKEM.LeafNode 现在要求最终实体证书的 subject public key（以密码套件中的签名编码表示）必须等于 X.509 凭据的 signature_key，否则拒绝该叶节点，包括空证书链或密钥类型与密码套件不匹配的证书；根据 RFC 9420 第 5.3.1 节，对信任锚点的证书链和身份验证仍由应用程序负责。仅使用基本凭据的部署不受影响。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.