CVE-2026-17508 in Bouncy Castle for Java
Résumé
par VulDB • 02/10/2026
Dans Bouncy Castle pour Java avant la version 1.86, plusieurs points d'entrée de dérivation de clés basés sur un mot de passe exécutaient le KDF avec des paramètres de coût extraits directement de l'entrée non fiable en cours de traitement, sans les limiter ; ainsi, une petite entrée pouvait imposer une quantité arbitraire de travail avant qu'une vérification du mot de passe ou de l'intégrité ne puisse la rejeter. Les chemins affectés sont les constructeurs de calculateur MAC PBMAC1 selon la RFC 9579, qui récupéraient le nombre d'itérations PBKDF2 et la longueur de clé dérivée directement depuis PBMAC1Params (JcePBMac1CalculatorBuilder, et PKCS12PBEUtils.createPBMac1Calculator accessible via PKCS12PfxPdu.isMacValid) ; le paramètre de parallélisation p du scrypt dans les garde-fous de coût des formats PKCS#8 et PKCS#12, qui ne limitait que le paramètre de coût N et la taille de bloc r bien que le tampon temporaire (scratch buffer) évolue avec r multiplié par p, permettant ainsi d'éviter entièrement le plafond mémoire configuré ; le fournisseur JCA PBKDF2 brut (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2) ; et le nombre de tours bcrypt lu depuis les kdfoptions propres à une clé privée OpenSSH v1 chiffrée. Chaque cas limite désormais ce paramètre avant la dérivation, conformément aux plafonds déjà appliqués ailleurs dans l'arborescence, avec un nombre de tours OpenSSH configurable via la nouvelle propriété org.bouncycastle.openssh.max_rounds. Cela complète les mesures de limitation initiées en version 1.85 pour les déchiffreurs PKCS#8 / PBES2 (CVE-2026-15055). Ce problème affecte également Bouncy Castle for Java LTS avant la version 2.73.13, ainsi que Bouncy Castle for Java FIPS (BC-FJA) avant les versions bcpkix-fips 1.0.13 (série 1.0.X), 2.0.13 (série 2.0.X) et 2.1.13 (série 2.1.X).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.