CVE-2026-14682 is an out-of-memory vulnerability in Bouncy Castle stemming from unbounded memory allocation when parsing definite-length BER/DER encoded data. In definite-length encoding, the message declares its own byte length before the content begins — this is the encoding form that was adopted specifically to avoid the vulnerabilities of indefinite-length parsing (which requires scanning for end markers). Bouncy Castle's parser reads this declared length and passes it directly to a memory allocation call without validating it against any reasonable bound. An attacker who can supply a crafted ASN.1 message to any Bouncy Castle parsing path — TLS handshake processing, certificate loading, CMS message decryption, signed document validation — can trigger arbitrary-sized memory allocation and cause OOM conditions.
The affected footprint is substantial: standard Java releases (1.85, 2.73.12), FIPS-certified variants across the 1.0.X, 2.0.X, and 2.1.X series, and the bctls-fips library. This breadth indicates the vulnerable logic lives in a shared decoder component that all variants inherit, making it a systemic design issue rather than an isolated coding error.
What makes this analytically significant is the threat model shift it represents. The security community has long recommended definite-length encoding specifically because length is known upfront — the implicit assumption became "definite equals safe to trust." Bouncy Castle faithfully implemented that mental model while delivering the opposite of its promise. The library correctly understands how many bytes are coming, but never asks whether that number is plausible. An attacker doesn't need to exploit parsing ambiguity; they need only provide a large but syntactically valid length field.
The FIPS-certified variants add a layer of concern: FIPS 140-2/140-3 certification validates cryptographic operations and key integrity but does not comprehensively audit BER/DER decoder memory allocation patterns. Organizations that rely on bc-fips may believe they're running validated code when this attack surface remains unexamined.
For defenders, the priority is determining whether your deployment feeds untrusted ASN.1 data into Bouncy Castle. Any application accepting certificates from untrusted sources, processing CMS messages from external entities, or terminating TLS where the peer is not fully trusted is potentially affected. Monitor memory consumption on processes handling these inputs, and evaluate whether application-layer bounds on decoded data size are warranted. The patch landscape is complex due to the multiple variant branches and FIPS re-certification requirements, so enterprise deployments should begin coordination now rather than waiting for an incident.