CVE-2026-71883 in BC-LTS-JAVA
Riassunto
di VulDB • 03/10/2026
In Bouncy Castle per Java LTS prima della versione 2.73.13, i cipher di pacchetto nativi one-shot per AES-CBC, CCM, CFB, CTR, GCM e GCM-SIV rilasciavano gli array dell'array delle chiavi del chiamante, IV (Initialisation Vector) e dei dati autenticati aggiuntivi con `ReleaseByteArrayElements` di JNI in modalità 0, che impegna la copia nativa nell'array Java. Questi array sono a sola lettura per il codice native; su una JVM che restituisce una copia anziché un pin (pinning), la copia mantiene ancora i byte di input così come sono stati letti. Il buffer di output viene gestito attraverso una regione critica separata e impegnato per primo, quindi dove un'applicazione ha passato lo stesso array Java sia come input che come destinazione - ad esempio crittografando in place su `KeyParameter.getKey()` -, il successivo rilascio in modalità 0 della chiave sovrascriveva i byte della chiave non modificati sul ciphertext appena prodotto. La chiamata restituiva ancora la lunghezza corretta dell'output, quindi un'applicazione che cripta in place sulla propria array di chiavi riceveva l'AES key grezzo dove si aspettava il ciphertext, senza alcun elemento nell'API a indicarlo, e trasmetteva o memorizzava la chiave al posto del messaggio. Gli input arrays a sola lettura sono ora rilasciati con `JNI_ABORT`, liberando la copia nativa senza copiarla indietro, e la modalità 0 è riservata agli array scritti dal codice native. I cipher di pacchetto puramente Java e le modalità streaming native non sono interessati. Bouncy Castle per Java (bcprov) non è interessato, in quanto non distribuisce implementazioni native.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.