CVE-2026-14682 is a high severity denial of service flaw (CVSS 7.5) in Bouncy Castle for Java. ASN.1 definite length parsing allocated the full declared object length up front, so a crafted header can exhaust memory. Fixed in 1.85, LTS 2.73.12, bc-fips 1.0.2.7 and bctls-fips 1.0.24.
What's affected
- Bouncy Castle for Java (bc-java) before 1.85, and the LTS line (bc-java LTS) before 2.73.12. Java 8 and later.
- Bouncy Castle FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), and bctls-fips before 1.0.24.
- Fixed: 1.85, LTS 2.73.12, bc-fips 1.0.2.7, 2.0.2, 2.1.3 and bctls-fips 1.0.24.
The Bouncy Castle advisory page gives no CVSS score or rating. The score here is the CVE record's: 7.5 High (availability only).
How to check if you're exposed
Bouncy Castle usually arrives as a transitive dependency, so start with the dependency tree rather than your own build file.
mvn dependency:tree -Dincludes=org.bouncycastle
gradle dependencies --configuration runtimeClasspath | grep -i bouncycastle
If you ship a fat jar or a container image, look inside the artifact too, because shaded copies do not show up in a dependency tree.
unzip -l app.jar | grep org/bouncycastle
Compare what you find with the fixed versions above. Services that read ASN.1 from a socket or TLS record layer are the main concern. Check bctls artifacts if you use Bouncy Castle for TLS.
Paste your manifest into the free in-browser dependency scan to see whether an affected version is in your tree. Nothing needs to be installed.
What to do now
- Find every Bouncy Castle copy in your build, including shaded and bundled ones.
- Upgrade to the fixed version for the line you use, listed above.
- Rebuild and redeploy, then confirm the new version with the same commands.
- Review services that parse ASN.1 from sockets, such as TLS or certificate reads, for memory limits.
Why it matters
The weakness is CWE-789 (Memory Allocation with Excessive Size Value). The advisory page says a crafted header read from a stream that cannot be rewound, such as a TLS record layer or a socket backed certificate read, could trigger an allocation close to the heap size before any content arrived.
The fix reads definite length objects incrementally, so a truncated input fails with an error that says the object was truncated, rather than a large allocation. Allocating from an untrusted length field is one of the oldest parser mistakes, and it recurs across this batch of Bouncy Castle CVEs. The record does not list the CVE as exploited.
Quick check
Why does the stream type matter?
With a non-rewindable stream, the parser cannot look ahead, so it allocated up front. The fix reads incrementally.
Which TLS artifact is covered?
bctls-fips before 1.0.24, per the advisory page.
Sources
Last reviewed: 18 October 2026.
