Bouncy Castle Java EUVD-2026-52132

Exploitation requires that the target Java application passes attacker-controlled data to Bouncy Castle's ASN.1 parser - specifically ASN1InputStream or any higher-level consumer such as X509CertificateHolder, CMS parsers, or PKCS decoders. The vulnerability is triggered specifically during definite-length ASN.1 object materialization when no bounded size limit smaller than the declared object length is enforced, which occurs when Bouncy Castle wraps a raw InputStream (non-array, non-file-backed) where StreamUtil.findLimit falls back to Runtime.maxMemory(). The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N reflects no authentication requirement for the attacker at the network level. Limiting factors: applications that parse only locally-generated or internally-signed cryptographic objects are not exploitable. Services that enforce a strict maximum input size before handing data to Bouncy Castle (e.g., rejecting payloads above 64 KB at the HTTP layer) are substantially protected in practice. There is no requirement for a specific non-default configuration; the flaw exists in the default ASN.1 parsing path.

The CVSS 4.0 score of 8.7 with AV:N/AC:L/AT:N/PR:N/UI:N/VA:H is consistent with the technical reality: any application passing network-supplied data to Bouncy Castle's ASN.1 parser is potentially exploitable with no authentication, user interaction, or complex preconditions required. The impact is strictly availability (VC:N/VI:N/VA:H, SC:N/SI:N/SA:N), making this a pure denial-of-service vector rather than a data-compromise risk. No EPSS data was included in the source intelligence, and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. The Amber urgency supplemental metric in the CVSS 4.0 vector signals the vendor views this as requiring timely but not immediate-emergency remediation. Real-world risk is elevated for deployments that parse untrusted ASN.1 data - certificate upload endpoints, TLS services using bctls-fips, and CMS/PKCS signature verification - but is low for environments where Bouncy Castle processes only internally trusted, pre-validated data. The breadth of affected release lines (standard, LTS, and FIPS-certified) substantially amplifies aggregate exposure across the Java ecosystem.

An attacker submits a 5-byte crafted DER-encoded OCTET STRING header to a Java web service that passes uploads to Bouncy Castle's ASN1InputStream - for example, a certificate upload endpoint or a CMS signature verification API. The header declares a near-JVM-heap payload length (e.g., 0x7FFFFFFF bytes) with no accompanying body bytes; the unpatched parser immediately calls new byte[2_147_483_647] before reading any data, triggering a JVM OutOfMemoryError that crashes the service thread or the entire JVM. No public proof-of-concept exploit has been identified at time of analysis, but the upstream commit includes a regression test that demonstrates the precise trigger mechanism.