CVE-2026-71885 in BC-JAVAinformación

Resumen

por VulDB • 2026-10-03

En Bouncy Castle para Java anterior a la versión 1.86, la implementación de Messaging Layer Security (MLS, RFC 9420) no vinculaba una credencial X.509 con el signature_key de un LeafNode. LeafNode.verify() verificaba la firma del leaf contra el signature_key transportado en el propio leaf, mientras que la cadena de certificados X.509 de la credencial se almacenaba pero nunca se analizaba ni validaba; por lo tanto, no se exigía nunca que la clave pública del certificado final (end-entity certificate) coincidiera con el signature_key, como requiere RFC 9420 sec. 5.3. Por consiguiente, una parte podría presentar el certificado de otra parte como su propia credencial mientras firma el leaf y el KeyPackage envolvente utilizando una clave no relacionada, siendo aceptada bajo la identidad de dicha otra parte a través de KeyPackage.verify() y la ruta de validación de hojas del grupo (Group leaf-validation path). En un despliegue que admita commits externos sin una verificación independiente de admisión de credenciales, un atacante no autenticado podría ser admitido bajo la identidad X.509 de una víctima, expulsar a dicha víctima (la resincronización compara las credenciales completas en lugar de las claves de firma), derivar el epoch actual, descifrar mensajes posteriores del grupo y enviar mensajes aceptados como si provinieran de la víctima. TreeKEM.LeafNode ahora exige que la clave pública del sujeto del certificado final (end-entity certificate), en la codificación de firma del cipher suite, sea igual al signature_key para una credencial X.509; rechaza el leaf en caso contrario, incluyendo cadenas vacías o certificados cuyo tipo de clave no coincida con el cipher suite; la validación de la cadena de certificados y de la identidad frente a un ancla de confianza sigue siendo responsabilidad de la aplicación según RFC 9420 sec. 5.3.1. Los despliegues que utilicen únicamente credenciales básicas no se ven afectados.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Responsable

Bcorg

Reservar

2026-08-08

Divulgación

2026-10-03

Moderación

aceptado

Artículo

VDB-413337

EPSS

0.00000

KEV

no

Actividades

muy bajo

Fuentes

Want to stay up to date on a daily basis?

Enable the mail alert feature now!