CVE-2026-71883 in BC-LTS-JAVA
Resumen
por VulDB • 2026-10-03
En Bouncy Castle para Java LTS anterior a la versión 2.73.13, los cifrados de paquetes nativos "one-shot" para AES-CBC, CCM, CFB, CTR, GCM y GCM-SIV liberaban las matrices del clave (key), el vector de inicialización (IV) y los datos autenticados adicionales del llamador utilizando `ReleaseByteArrayElements` de JNI en modo 0, lo que comprometía la copia nativa devolviéndola a la matriz Java. Esas matrices son de solo lectura para el código nativo; y en una JVM que devuelve una copia en lugar de fijar (pin) la referencia, dicha copia aún conserva los bytes de entrada tal como fueron leídos. El búfer de salida se procesa mediante una región crítica separada y se confirma primero, por lo que si una aplicación pasaba la misma matriz Java tanto como entrada como destino —por ejemplo, cifrando in situ sobre `KeyParameter.getKey()`—, la liberación posterior en modo 0 del clave sobrescribía los bytes de clave sin cambios sobre el texto cifrado que acababa de producirse. La llamada aún devolvía la longitud correcta de salida, por lo que una aplicación que cifra in situ su propia matriz de claves recibía la clave AES cruda donde esperaba texto cifrado, sin ningún indicio en la API al respecto, y transmitiría o almacenaría la clave en lugar del mensaje. Las matrices de entrada de solo lectura ahora se liberan con `JNI_ABORT`, lo que libera la copia nativa sin copiarla de vuelta, y el modo 0 está reservado para las matrices escritas por el código nativo. Los cifrados de paquetes puramente Java y los modos nativos en streaming no están afectados. Bouncy Castle para Java (bcprov) no se ve afectado, ya que no incluye implementaciones nativas.
If you want to get best quality of vulnerability data, you may have to visit VulDB.