CVE-2026-71886 in Bouncy Castle
Zusammenfassung
von VulDB • 03.10.2026
In Bouncy Castle for Java vor Version 1.86 akzeptierte die High-Level-OpenPGP-Zertifikats-API eine Zertifizierung oder Vertrauensdelegation durch Dritte von jedem Komponentenschlüssel des ausstellenden Zertifikats, ohne zu verlangen, dass dieser Schlüssel zur Zertifizierungsautorität ermächtigt worden war. OpenPGPCertificate.getCertificationBy() und getDelegationBy() lösen eine Signatur eines Dritten auf, indem sie deren Aussteller-Schlüsselkennung mit jedem Schlüssel des Drittanbieter-Zertifikats abgleichen, anschließend die Bindungskette der ausstellenden Komponente sowie die Signatur selbst verifizieren; dabei wurde nicht geprüft, ob der ausstellende Schlüssel bei Erstellung der Signatur das RFC-9580-Abschnitt-5.2.3.29-Zertifizierungsschlüsselkennzeichen (CERTIFY_OTHER) trug. Ein nur mit SIGN_DATA gebundener Subkey – also der Online-Signing-Subkey des exakt jenen Offline-Hauptschlüssel-Anordnungsmodells, für das diese Schlüsselkennzeichen existieren – konnte daher eine positive User-ID-Zertifizierung über eine vom Angreifer kontrollierte Identität oder eine direkte Vertrauensdelegation mit voller Vertrauenskette der Tiefe eins (Introducer Trust) ausstellen; die API gab dies als gültige Signaturkette zurück, die dem Drittanbieter-Zertifikat zugeordnet wurde. Eine Anwendung, die getCertificationBy(...).isValid() oder getDelegationBy(...) als Entscheidung über Identität oder vertrauenswürdigen Introducer wertet, würde die Behauptung des Angreifers dem Offline-Hauptschlüssel zuschreiben. Dies galt auch für einen Legacy-RSA-Subkey, der nur zur Verschlüsselung gebunden war, dessen Algorithmus jedoch dennoch signieren kann. Dadurch wird weder die Signatur des Hauptschlüssels gefälscht noch ein privater Schlüssel wiederhergestellt; stattdessen wird ein bereits kompromittierter, eingeschränkter Subkey zur Identitätsausstellungsautorität des Hauptschlüssels aufgewertet und damit das durch die Trennung der Schlüsselkennzeichen gewährte Containment ausgehebelt. Eine Zertifizierung oder Delegation durch Dritte wird nun nur noch dem ausstellenden Zertifikat zugeordnet, wenn der sie erstellende Komponentenschlüssel der Primärschlüssel ist oder ein Subkey mit CERTIFY_OTHER war, als die Signatur erstellt wurde; damit bleiben zertifizierungsfähige Subkeys weiterhin akzeptiert. Primärschlüssel werden unabhängig von ihren Schlüsselkennzeichen akzeptiert, da ein Primärschlüssel per Konstruktion zertifizierungsfähig ist und Zertifikate ohne Key-Flags-Subpacket insgesamt üblich sind. Dritte Widerrufe (Revocations) sind bewusst aus dieser Regel ausgeschlossen, da die Nichtanerkennung eines Widerrufs das Vertrauen aufrechterhalten würde, anstatt es zu entziehen.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.