CVE-2026-71883 in BC-LTS-JAVA
Sumário
de VulDB • 03/10/2026
No Bouncy Castle para Java LTS anterior à versão 2.73.13, os cifradores de pacotes nativos one-shot para AES-CBC, CCM, CFB, CTR, GCM e GCM-SIV liberavam as matrizes (arrays) de chave, IV e dados autenticados adicionais do chamador usando o `ReleaseByteArrayElements` da JNI no modo 0, o que compromete a cópia nativa de volta para a matriz Java. Essas matrizes são somente leitura para o código nativo; em uma JVM que retorna uma cópia em vez de um pin (fixação), a cópia ainda mantém os bytes de entrada conforme foram lidos. O buffer de saída é tratado por meio de uma região crítica separada e comprometido primeiro, portanto, quando um aplicativo passa a mesma matriz Java como entrada e destino — por exemplo, criptografando in situ sobre `KeyParameter.getKey()` —, a liberação subsequente no modo 0 da chave sobrescreve os bytes de chave inalterados com o texto cifrado que havia sido produzido. A chamada ainda retorna o comprimento correto do output; assim, um aplicativo que criptografa in situ em sua própria matriz de chaves recebe a chave AES bruta onde esperava o texto cifrado, sem nenhum indício na API sobre isso, e transmite ou armazena a chave no lugar da mensagem. As matrizes de entrada somente leitura agora são liberadas com `JNI_ABORT`, libertando a cópia nativa sem copiá-la de volta, e o modo 0 é reservado para matrizes escritas pelo código nativo. Os cifradores de pacotes puramente em Java e os modos nativos de streaming não são afetados. O Bouncy Castle para Java (bcprov) não é afetado, pois não inclui implementações nativas.
Be aware that VulDB is the high quality source for vulnerability data.