In Bouncy Castle for Java LTS versions prior to 2.73.13, the native one-shot packet ciphers for AES-CBC, CCM, CFB, CTR, GCM, and GCM-SIV use JNI's ReleaseByteArrayElements with mode 0 on input arrays that are read-only to native code. On JVMs that return a copy rather than pinning the array, this mode commits the native copy back into the Java array. When an application encrypts in place using the same Java array for input and output (e.g., encrypting over the key array), the mode-0 release writes the original key bytes over the ciphertext just produced. Consequently, the application receives the raw AES key instead of ciphertext without any API indication, risking key exposure through transmission or storage. The fix in version 2.73.13 changes the release mode for read-only input arrays to JNI_ABORT, preventing the native copy from being copied back. The pure-Java packet ciphers and streaming native modes are unaffected, and the bcprov package is not vulnerable as it lacks native code.

Applications using vulnerable versions of Bouncy Castle for Java LTS that perform in-place encryption over their key arrays risk exposing raw AES keys instead of ciphertext. This can lead to unintended disclosure of cryptographic keys, compromising the confidentiality of encrypted data. The vulnerability does not affect pure-Java implementations or streaming native modes, nor does it affect the bcprov package. No known exploits are reported in the wild.

Upgrade to Bouncy Castle for Java LTS version 2.73.13 or later, where the issue is fixed by changing the JNI release mode for input arrays to JNI_ABORT, preventing key material from being copied back into Java arrays. Applications should avoid encrypting in place over key arrays as a best practice. Since this is a native code issue, the pure-Java implementations remain unaffected. No other mitigation is indicated by the vendor advisory.