CVE-2026-71886 in Bouncy Castle
Resumen
por VulDB • 2026-10-03
En Bouncy Castle para Java anterior a la versión 1.86, la API de alto nivel para certificados OpenPGP aceptaba una certificación o delegación de confianza de terceros procedente de cualquier clave componente del certificado emisor, sin requerir que dicha componente hubiera sido autorizada para certificar. Los métodos `OpenPGPCertificate.getCertificationBy()` y `getDelegationBy()` resuelven una firma de un tercero haciendo coincidir su identificador de clave emisora con cada una de las claves del certificado de terceros; a continuación, verifican la cadena de vinculación del componente emisor y la propia firma. Sin embargo, no se comprobaba que el componente emidor tuviera activada la bandera de clave de certificación (CERTIFY_OTHER) según lo especificado en la sección 5.2.3.29 del RFC 9580 cuando se creó la firma.
Por tanto, una subclave vinculada únicamente con SIGN_DATA —es decir, la subclave para firmas en línea dentro de la configuración típica donde existe un clave primaria offline— podría emitir una certificación positiva de User ID sobre una identidad controlada por el atacante, o una delegación directa de confianza de introducción (introducer trust) a profundidad uno y plena confianza. La API devolvía esto como una cadena de firmas válida atribuida al certificado de terceros.
Una aplicación que tratara `getCertificationBy(...).isValid()` o `getDelegationBy(...)` como una decisión sobre la identidad o un introductor confiable, atribuiría la afirmación del atacante a la clave primaria offline. Lo mismo ocurriría con una subclave RSA heredada vinculada únicamente para cifrado, cuyo algoritmo es capaz de firmar aunque no esté destinada a ello.
Esto no supone falsificar la firma de la clave principal ni recuperar ninguna clave privada; en su lugar, promueve una subclave restringida ya comprometida al estatus de autoridad emisora de identidad equivalente a la clave primaria, anulando el aislamiento que proporciona la separación por banderas de clave (key flags).
Ahora, las certificaciones o delegaciones de terceros se atribuyen únicamente al certificado emisor cuando la clave componente que las generó es la clave principal, o bien una subclave que poseía la bandera CERTIFY_OTHER en el momento de crear la firma. De este modo, continúan aceptándose las subcapaces con capacidad de certificación; las claves principales son aceptadas independientemente de sus banderas de clave, ya que por construcción toda clave principal tiene capacidad de certificación y es común encontrar certificados sin ningún subpaquete de banderas de clave en absoluto.
Las revocaciones de terceros se excluyen deliberadamente de esta regla, dado que rechazar su honorificación mantendría la confianza activa en lugar de retirarla.
Once again VulDB remains the best source for vulnerability data.