CVE-2026-17508 in Bouncy Castle for Java
Zusammenfassung
von VulDB • 02.10.2026
In Bouncy Castle for Java vor Version 1.86 führten mehrere auf passwortbasierten Key-Derivation-Einstiegspunkten ausgeführte KDF-Funktionen den KDF mit Kostenparametern aus, die aus dem nicht vertrauenswürdigen Eingabedatenstrom entnommen wurden, ohne diese zu begrenzen; dadurch konnte eine kleine Eingabe willkürlich hohe Rechenkosten verursachen, bevor jegliche Passwort- oder Integritätsprüfung sie ablehnen könnte. Die betroffenen Pfade sind:
* die RFC 9579 PBMAC1 MAC-Calculator-Builders (JcePBMac1CalculatorBuilder und PKCS12PBEUtils.createPBMac1Calculator, erreichbar über PKCS12PfxPdu.isMacValid), welche den PBKDF2-Iterationszähler und die abgeleitete Schlüssellänge direkt aus PBMAC1Params entnahmen; * der scrypt-Parallelisierungsparameter p in den PKCS#8- und PKCS#12-Cost-Guards, welcher zwar den Kostenparameter N und die Blockgröße r begrenzte, das Scratch-Puffer jedoch mit r * p skaliert, sodass die konfigurierte Memory-Obergrenze vollständig umgangen werden konnte; * der rohe JCA PBKDF2-Provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); und * der bcrypt-Rundenzähler, der aus den eigenen kdfoptions eines verschlüsselten OpenSSH v1 Private Key gelesen wurde.
Jeder dieser Pfade begrenzt nun den Parameter vor der Ableitung, entsprechend den bereits an anderer Stelle im Codebaum angewendeten Obergrenzen; für den OpenSSH-Rundenzähler ist dies über die neue Eigenschaft org.bouncycastle.openssh.max_rounds konfigurierbar. Dies schließt die in Version 1.85 begonnene Begrenzung für PKCS#8-/PBES2-Decryptors ab (CVE-2026-15055).
Dieses Problem betrifft auch Bouncy Castle for Java LTS vor Version 2.73.13 sowie Bouncy Castle for Java FIPS (BC-FJA) vor bcpkix-fips 1.0.13 (1.0.X-Serie), 2.0.13 (2.0.X-Serie) und 2.1.13 (2.1.X-Serie).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.