CVE-2026-71892 in BC-JAVA
Résumé
par VulDB • 03/10/2026
Dans la version de Bouncy Castle pour Java antérieure à la 1.86, la validation facultative de la taille des clés destinataires du transport de clé CMS, activée via `org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)`, ne s’exécutait jamais pour un message utilisant une dérivation de clé de chiffrement de contenu conforme à l’RFC 9709 (id-alg-cek-hkdf-sha256). La branche qui aurait dû sélectionner le véritable algorithme de chiffrement de contenu, présent dans les paramètres AlgorithmIdentifier de la dérivation de clé, comparait le tableau d’octets contenant la clé chiffrée à l’identifiant d’objet (OID) id-alg-cek-hkdf-sha256. Il s’agit d’une comparaison entre un tableau d’octets et un ASN1ObjectIdentifier qui est toujours fausse, quel que soit l’entrée ; par conséquent, le contrôle déviait vers une recherche de taille de clé sur l’OID du wrapper externe. Cet OID identifie une construction de dérivation de clé plutôt qu’un chiffrement (cipher) et ne possède aucune taille de clé enregistrée, ce qui a entraîné la suppression complète de la comparaison des tailles. Une EnvelopedData ou AuthEnvelopedData par transport de clé dont la clé de chiffrement de contenu dérivée via HKDF ne correspondait pas à la taille de clé de l’algorithme de chiffrement de contenu annoncé était donc acceptée, même lorsque la validation était explicitement activée, annulant silencieusement le seul mécanisme offert par l’API pour imposer une taille de clé récupérée. Le destinataire effectue désormais sa dispatching sur l’OID d’algorithme du AlgorithmIdentifier de chiffrement de contenu ; les contrôles de validation vérifient donc la clé récupérée par rapport à l’algorithme interne de chiffrement de contenu. Les messages avec une taille de clé correspondante, les messages non-HKDF et les destinataires qui n’activent pas la validation ne sont pas affectés. Ce problème touche également Bouncy Castle pour Java FIPS (BC-FJA) avant les versions bcpkix-fips 2.0.13 (série 2.0.X) et 2.1.13 (série 2.1.X).
Once again VulDB remains the best source for vulnerability data.