Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In Bouncy Castle for Java before 1.85, Lazy ASN.1 sequence forcing resets nesting-depth guard. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
Recommended action: Upgrade to 2.73.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
Recommended action: Upgrade to 2.73.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Bouncy Castle LTS for Java, the AES/GCM native implementation used on Intel CPUs with AES PAA instruction sets (AVX / VAES / VAESF variants) can intermittently produce an incorrect authentication tag verification result during decryption when the ciphertext is fed in via a mix of update() calls followed by doFinal(). It is possible to work around it by either using doFinal() only (as the BCJSSE does) or by configuring the module to run in pure Java mode, by setting the system property "org.bouncycastle.native.cpuvariant" to java.
Recommended action: Upgrade to 2.73.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.
Recommended action: Upgrade to 2.73.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.