org.bouncycastle:bctls-fips 2.0.19.2

Direct Vulnerabilities

Known vulnerabilities in the org.bouncycastle:bctls-fips package. This does not include vulnerabilities belonging to this package’s dependencies.

Fix vulnerabilities automatically

Snyk's AI Trust Platform automatically finds the best upgrade path and integrates with your development workflows. Secure your code at zero cost.

Fix for free

Vulnerability	Vulnerable Version
C Improper Validation of Certificate with Host Mismatch Affected versions of this package are vulnerable to Improper Validation of Certificate with Host Mismatch in the `HostnameUtil` class, whose "match CN when no dNSName SAN exists" fallback is gated on `Properties.isOverrideSet(JSSE_HOSTNAME_CHECK_CN_FALLBACK, true)`, which returns true when the property is unset and so ships enabled by default, contrary to the documented opt-in behavior. An attacker can impersonate a target host and pass verification during a TLS handshake by presenting a certificate that carries no `dNSName` SAN and places the target hostname in its Common Name field. This applies only to certificates that lack a `dNSName` SAN and still chain to a trusted anchor, in deployments that have not explicitly set the fallback property to false. How to fix Improper Validation of Certificate with Host Mismatch? Upgrade `org.bouncycastle:bctls-fips` to version 1.0.24, 2.0.24, 2.1.24 or higher.	[,1.0.24)[2.0.19,2.0.24)[2.1.20,2.1.24)
H Memory Allocation with Excessive Size Value Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the `processRecord()` method of `DTLSReliableHandshake`, where the `DTLSReassembler` constructor allocates a `byte[length]` buffer directly from the 24-bit handshake length field without checking it against `peer.getMaxHandshakeMessageSize()`, unlike the stream-TLS path. An attacker can drive the JVM to `OutOfMemoryError` with a handful of small UDP datagrams by sending a single ~205-byte epoch-0 record carrying 16 fragment headers with `length=0xFFFFFF` and `fragment_length=0`, forcing roughly 256 MiB of allocation before any authentication. This requires only the ability to send UDP records to a DTLS listener, with each connection buffering up to 16 `message_seq` values. How to fix Memory Allocation with Excessive Size Value? Upgrade `org.bouncycastle:bctls-fips` to version 1.0.24, 2.0.24, 2.1.24 or higher.	[,1.0.24)[2.0.19,2.0.24)[2.1.20,2.1.24)

Vulnerability

Vulnerable Version

Improper Validation of Certificate with Host Mismatch

Affected versions of this package are vulnerable to Improper Validation of Certificate with Host Mismatch in the HostnameUtil class, whose "match CN when no dNSName SAN exists" fallback is gated on Properties.isOverrideSet(JSSE_HOSTNAME_CHECK_CN_FALLBACK, true), which returns true when the property is unset and so ships enabled by default, contrary to the documented opt-in behavior. An attacker can impersonate a target host and pass verification during a TLS handshake by presenting a certificate that carries no dNSName SAN and places the target hostname in its Common Name field. This applies only to certificates that lack a dNSName SAN and still chain to a trusted anchor, in deployments that have not explicitly set the fallback property to false.

How to fix Improper Validation of Certificate with Host Mismatch?

Upgrade org.bouncycastle:bctls-fips to version 1.0.24, 2.0.24, 2.1.24 or higher.

[,1.0.24)[2.0.19,2.0.24)[2.1.20,2.1.24)

Memory Allocation with Excessive Size Value

Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the processRecord() method of DTLSReliableHandshake, where the DTLSReassembler constructor allocates a byte[length] buffer directly from the 24-bit handshake length field without checking it against peer.getMaxHandshakeMessageSize(), unlike the stream-TLS path. An attacker can drive the JVM to OutOfMemoryError with a handful of small UDP datagrams by sending a single ~205-byte epoch-0 record carrying 16 fragment headers with length=0xFFFFFF and fragment_length=0, forcing roughly 256 MiB of allocation before any authentication. This requires only the ability to send UDP records to a DTLS listener, with each connection buffering up to 16 message_seq values.

How to fix Memory Allocation with Excessive Size Value?

Upgrade org.bouncycastle:bctls-fips to version 1.0.24, 2.0.24, 2.1.24 or higher.

[,1.0.24)[2.0.19,2.0.24)[2.1.20,2.1.24)

org.bouncycastle:bctls-fips@2.0.19.2

latest version

latest non vulnerable version

first published

latest version published

licenses detected

package registry

Direct Vulnerabilities

Fix vulnerabilities automatically