CVE-2026-71883 in BC-LTS-JAVA
Summary
by MITRE • 10/03/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java LTS prior to version 2.73.13 represents a critical memory management flaw within the JNI-based implementation of one-shot native packet ciphers. This issue specifically affects algorithms including AES-CBC, CCM, CFB, CTR, GCM, and GCM-SIV when utilizing their native implementations. The core technical defect lies in the improper handling of Java array buffers during the encryption process via the Java Native Interface. Specifically, the library utilized JNI's ReleaseByteArrayElements function with mode 0 for input arrays that were designated as read-only by the native code. In environments where the JVM returns a copy of the array rather than pinning it to memory, this action commits the unchanged native copy back into the original Java array after the encryption operation has completed. This behavior is fundamentally incorrect because mode 0 is intended exclusively for scenarios where the native code has modified the data and needs to write those changes back to the caller.
The operational impact of this flaw becomes severe when an application attempts to perform in-place encryption, a common optimization technique where the input buffer serves simultaneously as the destination for the ciphertext. In such configurations, particularly when passing the same Java array containing sensitive material like KeyParameter.getKey() data as both the source and target buffers, the sequence of operations leads to catastrophic data corruption. The output buffer is processed through a separate critical region and committed first, resulting in valid ciphertext being generated within that memory space. However, immediately following this step, the flawed release mechanism for the input array triggers a write-back operation using mode 0. This action overwrites the freshly produced ciphertext with the original, unencrypted key bytes from the native copy. Consequently, the application receives an output length indicating success but is handed raw cryptographic keys instead of encrypted data.
This misdirection creates a profound security risk as applications typically assume that successful API calls yield valid ciphertext ready for transmission or storage. Without any explicit indication in the API to signal this corruption, systems may proceed to transmit or store these plaintext key arrays under the assumption they are secure messages. This results in the direct exposure of long-term cryptographic secrets, effectively nullifying all confidentiality guarantees provided by the encryption algorithm. The vulnerability is classified as CWE-787: Out-of-bounds Write and CWE-200: Exposure of Sensitive Information to an Unauthorized Actor because it involves writing data beyond its intended logical scope due to incorrect buffer management semantics, leading directly to information disclosure.
The remediation strategy implemented in version 2.73.13 addresses this by modifying the JNI calls for read-only input arrays to use mode 0 with the JNI_ABORT flag. This change ensures that the native copy is freed without copying any data back into the Java array, thereby preventing the accidental overwrite of ciphertext with plaintext key material. Mode 0 remains reserved strictly for cases where the native code has legitimately modified the buffer contents and requires those changes to be reflected in the JVM heap. It is important to note that this vulnerability does not affect pure-Java implementations of packet ciphers or streaming native modes, nor does it impact Bouncy Castle for Java (bcprov) which lacks these specific native implementations. Organizations relying on affected versions must upgrade immediately to prevent potential key leakage and ensure compliance with secure coding standards regarding memory management in hybrid native-managed code environments.