Bouncy Castle Java CVE-2026-59646

The target application must use Bouncy Castle's DTLS stack (bc-java, bc-lts-java, or bctls-fips) for network communication and must have a DTLS endpoint reachable by the attacker over UDP. The vulnerable allocation occurs pre-authentication - no valid credentials, prior session state, or completed handshake is required. Because DTLS is UDP-based, source address spoofing is possible on networks lacking BCP38 filtering, enabling amplification-style DoS from spoofed sources. Exploitation is scoped exclusively to the DTLS handshake path; applications using Bouncy Castle only for TLS/TCP, JCE cryptographic operations (signing, encryption), or PKIX without a DTLS transport layer are not vulnerable via this code path. Sustained or repeated connection attempts are likely required to exhaust memory on a well-provisioned JVM rather than a single packet, which may provide a detection window in network flow monitoring.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) accurately reflects the threat model: any unauthenticated network attacker can trigger repeated large heap allocations with crafted UDP packets, and no special attack preconditions are required. Impact is limited entirely to availability; the CVSS vector confirms no confidentiality or integrity exposure. Notably, the 'Information Disclosure' tag in the source intelligence is inconsistent with the CVSS impact metrics (VC:N) - no confidentiality impact is established by the description or the patch diff, and this tag appears to be a classification artifact or secondary concern not elaborated in the advisory; security teams should not assume data exposure. EPSS data was not provided, leaving quantified exploitation probability unestimated from that source. The vulnerability is not in CISA KEV and no public exploit code has been identified, reducing urgency somewhat relative to the raw score. However, AV:N/AC:L/PR:N/UI:N makes this trivially automatable against any internet-exposed DTLS endpoint. Real-world risk is highest for Java services using Bouncy Castle's DTLS stack exposed to untrusted networks (e.g., DTLS-based IoT gateways, VoIP, WebRTC backends, or FIPS-regulated financial services using BC-FJA). Applications using Bouncy Castle only for TLS-over-TCP or for non-transport cryptography are unaffected by this specific path.

An attacker with UDP reachability to a Java server's DTLS port sends a flood of crafted DTLS handshake records, each advertising a 24-bit message length near the maximum (~16MB), targeting the reassembler before any handshake authentication completes. Each malicious record causes the server to allocate a large heap buffer; repeated at sufficient rate, this exhausts the JVM heap and triggers an OutOfMemoryError, crashing the service or causing severe degradation. No public exploit code has been released, but the attack requires only UDP socket access and knowledge of the DTLS record format, both of which are publicly documented.