org.bouncycastle:bcpkix-jdk14@1.62

Affected versions of this package are vulnerable to Improper Certificate Validation. PKIXCertPathReviewer.checkNameConstraints() in org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer and org.bouncycastle.x509.PKIXCertPathReviewer. An attacker can get a constrained certificate chain accepted by supplying a leaf certificate whose subject DN or subjectAltName violates the issuing CA’s NameConstraints extension. When an application relies on the reviewer’s isValidCertPath() result for trust decisions, it accepts an end-entity certificate that the CA was not authorized to issue, allowing unauthorized certificate acceptance.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.86 or higher.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due to unbounded PBKDF2 parameters in the PBMAC1 key-derivation path in JcePBMac1CalculatorBuilder and PKCS12PBEUtils.createPBMac1Calculator. An attacker can force excessive PBKDF2 work by supplying a crafted PBMAC1- or PKCS#12-wrapped structure with a very large iteration count or derived key length before any password or MAC check runs. This stalls PBMAC1 verification of PKCS#12 PFX and CMP data and can tie up the process on attacker-controlled input.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.86 or higher.

Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in CMS AuthEnvelopedData recipient processing, where AbstractRecipient and its recipient classes (such as JceKeyTransRecipient and BcKeyTransRecipient) take the AEAD tag length from the attacker-controlled GCM or CCM ICV length in the content AlgorithmIdentifier without a minimum-length check. An attacker can reduce the authentication tag to a length that makes forgery tractable by setting that MAC length to a small value such as 32 bits, so the recipient verifies against a short tag. The forged message must still verify against the shortened tag, so this enables a feasible brute-force forgery rather than an immediate bypass, and it affects applications decrypting AuthEnvelopedData with no configured minimum tag size.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.85 or higher.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in PKCS12KeyStoreSpi, which feeds the attacker-controlled KDF iteration count from a PKCS#12 file's MAC data and encrypted bags into key derivation during engineLoad() without enforcing any upper bound. An attacker can pin a CPU core for an extended period and exhaust server resources by supplying a PKCS#12 keystore whose MAC or bag PBE parameters declare a very large iteration count, up to 2^31-1. This requires the application to load the attacker-supplied keystore, and the costly derivation runs during MAC verification and bag decryption regardless of whether the supplied password matches.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.85 or higher.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in JcePKCSPBEInputDecryptorProviderBuilder and JceOpenSSLPKCS8DecryptorProviderBuilder, which parse PBES2Parameters from attacker-supplied EncryptedPrivateKeyInfo, PKCS#12, or CMS structures and pass the scrypt N/r and PBKDF2 iteration count straight into key derivation without bounds checking. An attacker can exhaust the JVM heap (roughly 128*N*r bytes of scrypt memory) or pin a worker thread for extended periods with up to 2^31-1 PBKDF2 iterations, by submitting an encrypted private key, PKCS#12 file, or CMS message that declares large KDF cost parameters. The key derivation runs before any integrity or authenticity check, so exploitation only requires the application to attempt password-based decryption or PKCS12PfxPdu MAC verification of the attacker-supplied structure.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.85 or higher.

Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature in the CMSSignedData.verifySignatures(SignerInformationVerifierProvider, boolean) method, which iterates the signer set and returns true on loop completion without checking that any signer is present. An attacker can have completely unsigned content accepted as authentic by submitting a degenerate CMS or PKCS#7 SignedData that carries arbitrary content with an empty signerInfos set, which RFC 5652 permits. This affects applications that treat the true return value as proof of authenticity without separately asserting that an expected signer is present.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.85 or higher.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the PKMACValueVerifier.isValid() and ProtectedPKIMessage.verify() verification paths, where PKMACBuilder's default constructor leaves maxIterations = 0 and disables the iteration-count ceiling, so an attacker-supplied PBMParameter iteration count drives the do { K = digest(K); } while (--iter > 0); loop without bound. An attacker can tie up a server thread for hours per request and exhaust the thread pool with a handful of requests by setting iterationCount to 2^31-1 in a password-MAC protected CMP or CRMF message. This affects endpoints that verify PBM-protected CMP/CRMF messages, or CMS PasswordRecipientInfo via BcPasswordRecipient, using a PKMACBuilder left at its default with no iteration ceiling, such as CAs and RAs.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.85 or higher.

Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the getContentStream() method of RecipientInformation, which, when authenticated attributes are present, authenticates only the DER-encoded authAttrs and never checks the computed content digest against the messageDigest attribute required by RFC 5652 section 9.3. An attacker who intercepts a CMS AuthenticatedData message can substitute arbitrary content that still passes verification by replacing encapContentInfo.eContent while leaving authAttrs and the MAC untouched. This applies when the message carries authenticated attributes and the application follows the documented pattern of comparing only ad.getMac() to recipient.getMac() without separately validating the content digest.

Upgrade org.bouncycastle:bcpkix-jdk14 to version 1.85 or higher.