Bouncy Castle Java EUVD-2026-52137

The target application must be using bc-java's MLS submodule - specifically any code path that calls MLSInputStream.readOpaque() on data received from a network source. The CVSS vector (PR:N, UI:N) confirms no authentication or user interaction is required. The vulnerable allocation is reached before any MLS signature or MAC verification, so triggering it requires only the ability to deliver a small TCP or application-layer message to an endpoint that decodes MLS wire format. Applications using bc-java exclusively for non-MLS functions (TLS, PGP, S/MIME, CMS, PKIX) are entirely unaffected. Exploitation is limited to availability impact (heap exhaustion leading to JVM crash); no path to confidentiality or integrity compromise is present.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) and score of 8.7 accurately characterize the threat: low-complexity, unauthenticated, remotely automatable with high availability impact. There is no confidentiality or integrity impact confirmed by the vector or the commit diff, making the 'Information Disclosure' tag in the source data appear to be a tagging error - no data exfiltration path is described or evidenced anywhere in the available intelligence. EPSS data was not provided in the input, so exploitation probability cannot be quantified beyond the structural assessment. KEV status is absent, meaning active exploitation is not confirmed. The primary real-world risk moderator is MLS deployment footprint: the MLS submodule is a newer addition to bc-java and MLS is not yet broadly adopted in production Java applications, meaningfully reducing exposure relative to the CVSS score alone. Applications using bc-java only for TLS, PGP, S/MIME, or other non-MLS functions are entirely unaffected.

An unauthenticated remote attacker sends a crafted 4-byte MLS wire message containing a Varint field encoding a declared length of 0x3FFFFFFF (approximately 1 GiB) with no subsequent data bytes. The MLSInputStream decoder allocates a 1 GiB byte array before detecting the input is shorter than declared, instantly consuming available JVM heap. Repeating this with a small number of concurrent connections exhausts the heap, triggering OutOfMemoryError and crashing the service. No public exploit code has been identified, but the attack is directly constructable from the regression test added in the fix commit.