CVE-2026-59645 is a high severity denial of service in Bouncy Castle for Java. The OER parser for IEEE 1609.2 messages recurses without a depth limit, so a small nested message causes a StackOverflowError. Fixed in 1.85, LTS 2.73.12 and bcutil-fips 2.0.7 and 2.1.7.
What's affected
- Bouncy Castle for Java: before 1.85, affected from 1.70 according to the project advisory.
- Bouncy Castle for Java LTS: before 2.73.12.
- Bouncy Castle FIPS: before bcutil-fips 2.0.7 (2.0.X) and 2.1.7 (2.1.X).
- Platform: Java 8 and later.
- Who is exposed: code that parses untrusted IEEE 1609.2 data, used in vehicle to everything (V2X) systems, through the ETSI signed data and encrypted data classes.
How to check if you're exposed
Find which Bouncy Castle artifacts and versions your build resolves, including indirect ones.
mvn dependency:tree -Dincludes=org.bouncycastle
./gradlew dependencies --configuration runtimeClasspath | grep -i bouncycastle
Look for artifacts such as bcprov, bcpkix, bcpg and bctls, and compare the version with the fixed versions above. Check shaded or fat jars and container images as well, because Bouncy Castle is often bundled inside other libraries and a copy can hide there.
Search your code for ETSISignedData and ETSIEncryptedData, and for OERInputStream. These are the public entry points the advisory names. If you do not parse IEEE 1609.2 or ETSI security messages, you do not reach the vulnerable code. If you do, find out where the bytes come from: parsing happens before any signature verification, so any sender can reach it.
What to do now
- Upgrade to Bouncy Castle 1.85, LTS 2.73.12, or bcutil-fips 2.0.7 or 2.1.7.
- Enforce a maximum message size before parsing, since the advisory says a few kilobytes are enough.
- Catch StackOverflowError at the message handling boundary and drop the message, so one bad packet does not kill a worker thread.
- Monitor for repeated parse failures from the same sender.
- Run the free in-browser dependency scan on your lockfile or manifest to see every affected package in one pass.
Why it matters
The weakness is CWE-674 (Uncontrolled Recursion). The advisory says the bundled IEEE 1609.2 schema has a cycle, from the data type to the signed data content and payload and back again, and that the parser walks children recursively with no depth counter. A flag meant to mark such recursion was only checked by test tooling, not by the runtime parser.
Each nested level costs a handful of input bytes but around five stack frames. A message of two to four kilobytes with hundreds of nested payloads exhausts the stack and throws StackOverflowError before any signature check. The record scores it 7.5 (High) and does not mark it as exploited in the wild.
Quick check
Is signature verification a defence here?
No. The advisory says parsing runs on untrusted bytes before any signature is verified, so a signature check does not help.
Sources
Last reviewed: 18 October 2026.
