CVE-2026-71883: CWE-200 Exposure of Sensitive Information to an Unauthorized Actor in Legion of the Bouncy Castle Inc. BC-LTS-JAVA
In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0, which commits the native copy back into the Java array. Those arrays are read-only to the native code, and on a JVM that returns a copy rather than a pin the copy still holds the input bytes as they were read. The output buffer is taken through a separate critical region and committed first, so where an application passed the same Java array as both an input and the destination - encrypting in place over KeyParameter.getKey(), for example - the later mode-0 release of the key wrote the unchanged key bytes over the ciphertext that had just been produced. The call still returned the correct output length, so an application encrypting in place over its own key array was handed the raw AES key where it expected ciphertext, with nothing in the API to indicate it, and would transmit or store the key in place of the message. The read-only input arrays are now released with JNI_ABORT, freeing the native copy without copying it back, and mode 0 is reserved for arrays the native code wrote. The pure-Java packet ciphers and the streaming native modes are not affected. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.
AI Analysis
Technical Summary
In BC-LTS-JAVA versions >=2.73.4 and <2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM, and GCM-SIV improperly release the caller's key, IV, and additional authenticated data arrays using JNI's ReleaseByteArrayElements in mode 0. This mode commits the native copy back into the Java array, which is read-only to native code. On JVMs that return a copy rather than pinning the array, this results in the native copy holding the original input bytes. When an application encrypts in place over the same Java array used for the key, the mode-0 release overwrites the ciphertext with the unchanged key bytes, causing the application to receive the raw AES key instead of ciphertext. The vulnerability was fixed by changing the release mode to JNI_ABORT for read-only input arrays, preventing the native copy from being copied back. The pure-Java packet ciphers and streaming native modes are unaffected, and bcprov is not affected as it lacks native implementations.
Potential Impact
This vulnerability can lead to exposure of the raw AES encryption key in place of the ciphertext when applications encrypt data in place over the key array. This could cause sensitive cryptographic keys to be inadvertently transmitted or stored, compromising confidentiality. The vulnerability affects confidentiality but does not impact integrity or availability. There are no known exploits in the wild at this time.
Mitigation Recommendations
A fix is available in BC-LTS-JAVA versions 2.73.13 and later, which changes the JNI release mode to prevent the native copy of input arrays from being copied back to Java arrays. Users should upgrade to version 2.73.13 or later to remediate this vulnerability. No other mitigation is indicated.
CVE-2026-71883: CWE-200 Exposure of Sensitive Information to an Unauthorized Actor in Legion of the Bouncy Castle Inc. BC-LTS-JAVA
Description
In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0, which commits the native copy back into the Java array. Those arrays are read-only to the native code, and on a JVM that returns a copy rather than a pin the copy still holds the input bytes as they were read. The output buffer is taken through a separate critical region and committed first, so where an application passed the same Java array as both an input and the destination - encrypting in place over KeyParameter.getKey(), for example - the later mode-0 release of the key wrote the unchanged key bytes over the ciphertext that had just been produced. The call still returned the correct output length, so an application encrypting in place over its own key array was handed the raw AES key where it expected ciphertext, with nothing in the API to indicate it, and would transmit or store the key in place of the message. The read-only input arrays are now released with JNI_ABORT, freeing the native copy without copying it back, and mode 0 is reserved for arrays the native code wrote. The pure-Java packet ciphers and the streaming native modes are not affected. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.
CVSS v4.0
Score 8.2high
Affected software
Legion of the Bouncy Castle Inc.
BC-LTS-JAVA
pkg:github/bcprov-lts8onRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
In BC-LTS-JAVA versions >=2.73.4 and <2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM, and GCM-SIV improperly release the caller's key, IV, and additional authenticated data arrays using JNI's ReleaseByteArrayElements in mode 0. This mode commits the native copy back into the Java array, which is read-only to native code. On JVMs that return a copy rather than pinning the array, this results in the native copy holding the original input bytes. When an application encrypts in place over the same Java array used for the key, the mode-0 release overwrites the ciphertext with the unchanged key bytes, causing the application to receive the raw AES key instead of ciphertext. The vulnerability was fixed by changing the release mode to JNI_ABORT for read-only input arrays, preventing the native copy from being copied back. The pure-Java packet ciphers and streaming native modes are unaffected, and bcprov is not affected as it lacks native implementations.
Potential Impact
This vulnerability can lead to exposure of the raw AES encryption key in place of the ciphertext when applications encrypt data in place over the key array. This could cause sensitive cryptographic keys to be inadvertently transmitted or stored, compromising confidentiality. The vulnerability affects confidentiality but does not impact integrity or availability. There are no known exploits in the wild at this time.
Mitigation Recommendations
A fix is available in BC-LTS-JAVA versions 2.73.13 and later, which changes the JNI release mode to prevent the native copy of input arrays from being copied back to Java arrays. Users should upgrade to version 2.73.13 or later to remediate this vulnerability. No other mitigation is indicated.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- bcorg
- Date Reserved
- 2026-08-08T00:06:06.982Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6ac0c0f9a43b0b3b89b059b8
Added to database: 10/03/2026, 08:46:49 UTC
Last enriched: 10/03/2026, 09:01:18 UTC
Last updated: 10/04/2026, 05:45:56 UTC
Views: 20
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.