CVE-2026-71892 in BC-JAVA
Zusammenfassung
von VulDB • 03.10.2026
In Bouncy Castle für Java vor Version 1.86 führte die opt-in-Validierung der Schlüsselgröße bei CMS Key-Transport-Empfängern, `org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)`, nie eine Prüfung durch, wenn eine Nachricht mit einer RFC-9709-Inhaltsverschlüsselungsschlüsselableitung (id-alg-cek-hkdf-sha256) verwendet wurde. Der Zweig, der den tatsächlichen Inhaltsverschlüsselungsalgorithmus aus den Parametern des AlgorithmIdentifier für die Schlüsselableitung auswählen sollte, verglich das verschlüsselte-Schlüssel-Bytearray mit dem Object Identifier (OID) von id-alg-cek-hkdf-sha256. Dies ist ein Vergleich zwischen einem Bytearray und einer ASN1ObjectIdentifier-Klasse, der bei jeder möglichen Eingabe falsch ausfällt, sodass die Prüfung an eine Schlüsselgrößenabfrage für den äußeren Wrapper-OID vorbeilief. Dieser OID identifiziert eine Schlüsselaableitungskonstruktion statt eines Chiffriersystems und hat keine registrierte Schlüsselgröße, daher wurde der Größenvergleich vollständig übersprungen. Ein Key-Transport EnvelopedData oder AuthEnvelopedData, dessen transportierter, HKDF-abgeleiteter Inhaltsverschlüsselungsschlüssel nicht mit der Schlüsselgröße des angegebenen Inhaltsverschlüsselungsalgorithmus übereinstimmte, wurde daher akzeptiert, auch wenn die Validierung explizit aktiviert war. Dies untergrub stillschweigend den einzigen Mechanismus, den die API zur Durchsetzung der wiederhergestellten Schlüsselgröße bietet. Der Empfänger dispatchet nun basierend auf dem Algorithm-OID des Inhaltsverschlüsselung-AlgorithmIdentifiers, sodass die Validierungsprüfungen den wiederhergestellten Schlüssel gegen den inneren Inhaltsverschlüsselungsalgorithmus prüfen. Nachrichten mit einer übereinstimmenden Schlüsselgröße, nicht-HKDF-Nachrichten und Empfänger, die keine Validierung aktivieren, sind unbetroffen. Dieses Problem betrifft auch Bouncy Castle für Java FIPS (BC-FJA) vor bcpkix-fips 2.0.13 (2.0.X-Serie) und 2.1.13 (2.1.X-Serie).
Once again VulDB remains the best source for vulnerability data.