CVE-2022-45146 is a use-after-free vulnerability in the Bouncy Castle BC-FJA (FIPS Java API) that appears when the library runs on Java 13 or later, in versions before 1.0.2.4. Under those JVMs, temporary cryptographic keys the module allocates can be zeroed out by the garbage collector while the module is still using them, causing errors or potential loss of the sensitive material being processed.
It was published on 21 November 2022 and rated CVSS 5.5 (Medium), classified as CWE-416 (Use After Free). It is not a remote-code-execution bug and there is no known exploit that leaks keys to an attacker over the network — the practical impact is correctness and reliability of cryptographic operations, plus the theoretical information-integrity concern that comes with any use-after-free in a crypto module.
Why a garbage collector triggers a crypto bug
BC-FJA manages temporary key material during certain operations and, in older versions, relied on assumptions about object lifetime that held on earlier JVMs. Java 13 changed behavior in the garbage collector. Under the newer GC, the runtime can reclaim or zero out the buffers holding those temporary keys while the module still has work to do with them.
The result is a classic use-after-free: memory that has been "freed" (here, zeroed) is read or used again. In a general application that often means a crash or corrupted data. In a FIPS crypto module it can mean a failed operation or garbled output, because the key the module expected to be present has been wiped mid-flight.
The trigger is the runtime, not the caller. You do not have to do anything unusual in your code to hit it — running an affected BC-FJA build on Java 13+ is enough to be in scope.
An important caveat for FIPS users
There is a nuance worth stating plainly: users relying on FIPS certification are not affected in the same way, because the BC-FJA FIPS certification applies to Java 7, 8, and 11. If you deploy strictly on a certified JVM (7, 8, or 11), you are outside the Java-13-and-later condition that triggers the flaw.
The exposure appears when teams run the FIPS module on a newer, uncertified JVM — which is easy to do by accident during an upgrade, when a base image bumps the JDK and nobody re-checks the crypto module's supported matrix. That mismatch is the real-world way this CVE bites.
Confirming your exposure
Check two things: the BC-FJA version and the JVM you actually run on.
For the dependency version in Maven:
mvn dependency:tree -Dincludes=org.bouncycastle:bc-fips
The affected artifact is the FIPS distribution (bc-fips), not the general-purpose bcprov-jdk18on provider. If the resolved version is below 1.0.2.4, you have the vulnerable code.
Then confirm the runtime:
java -version
If that reports Java 13 or later and you are on a bc-fips release before 1.0.2.4, both conditions are met. A software composition analysis workflow will flag the vulnerable bc-fips artifact automatically, which matters here because crypto libraries are often pulled in transitively by a framework rather than declared directly.
How to fix CVE-2022-45146
Upgrade Bouncy Castle's FIPS Java API to 1.0.2.4 or later. In Maven:
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bc-fips</artifactId>
<version>1.0.2.4</version>
</dependency>
If you cannot upgrade the library right away and you require the FIPS module specifically, the certification-scoped mitigation is to run on a supported JVM — Java 7, 8, or 11 — where the triggering GC behavior is not present. That is a deliberate constraint rather than a patch, so track it as technical debt and upgrade the library when you can, since pinning yourself to an older JVM has its own security cost.
What this teaches about crypto dependencies
Two lessons carry beyond this single CVE:
- Supported-runtime matrices are part of your security posture. A JDK bump in a base image can silently move a crypto module outside its certified or tested range. Track the JVM version alongside the library version.
- Transitive crypto pulls deserve scrutiny. Bouncy Castle frequently arrives through a higher-level dependency. Scanning your full dependency graph, not just direct declarations, is how you catch a
bc-fipsversion you did not knowingly add. The same discipline that catches Log4Shell in the log4j-core dependency catches this.
FAQ
What is the affected version for CVE-2022-45146?
Bouncy Castle BC-FJA (the bc-fips FIPS Java API) before version 1.0.2.4, when running on Java 13 or later. Upgrade to 1.0.2.4 or newer.
Is CVE-2022-45146 exploitable by an attacker?
There is no known remote exploit. It is a use-after-free (CWE-416) rated CVSS 5.5 (Medium) whose practical effect is errors or potential information loss during crypto operations, not remote code execution or a network-facing key leak.
Are FIPS-certified deployments affected?
The FIPS certification for BC-FJA applies to Java 7, 8, and 11. If you run strictly on one of those certified JVMs, you are outside the Java-13-and-later condition that triggers the bug. The risk appears when the module runs on a newer, uncertified JVM.
Does this affect the regular Bouncy Castle provider?
This CVE targets the FIPS distribution (bc-fips). Confirm which Bouncy Castle artifact your project actually depends on before assuming you are in or out of scope.