CVE-2026-71883 in BC-LTS-JAVA
Zusammenfassung
von VulDB • 03.10.2026
In Bouncy Castle für Java LTS vor Version 2.73.13 gaben die One-Shot-Native-Paket-Ciphers für AES-CBC, CCM, CFB, CTR, GCM und GCM-SIV die Arrays des Aufrufers mit Schlüssel (Key), Initialisierungsvektor (IV) und zusätzlichen authentifizierten Daten über JNI's ReleaseByteArrayElements im Modus 0 frei, was den nativen Kopiervorgang zurück in das Java-Array schreibt. Diese Arrays sind für den Native-Code schreibgeschützt, und bei einer JVM, die eine Kopie statt eines Pinnings (Pin) zurückgibt, enthält diese Kopie weiterhin die Eingabedaten so, wie sie gelesen wurden. Der Ausgabepuffer wird durch einen separaten kritischen Bereich geführt und zuerst committed; daher führt der spätere Release des Schlüssels im Modus 0 dazu, dass die unveränderten Schlüsselbytes den gerade erzeugten Chiffretext überschreiben, wenn eine Anwendung das gleiche Java-Array sowohl als Eingabe als auch als Ziel verwendet (z. B. beim In-Place-Verschlüsseln über KeyParameter.getKey()). Der Aufruf gibt zwar die korrekte Ausgabelänge zurück, sodass einer Anwendung, die in ihrem eigenen Schlüsselarray verschlüsselt, der rohe AES-Schlüssel dort bereitgestellt wird, wo sie Chiffretext erwartet; nichts im API deutet darauf hin, und das System würde den Schlüssel anstelle der Nachricht übertragen oder speichern. Die schreibgeschützten Eingabe-Arrays werden nun mit JNI_ABORT freigegeben, wodurch die native Kopie ohne Zurückkopieren in Java gelöscht wird, und Modus 0 ist für Arrays reserviert, die vom Native-Code geschrieben wurden. Die rein-Java-Paket-Ciphers sowie die Streaming-Native-Modi sind nicht betroffen. Bouncy Castle für Java (bcprov) ist nicht betroffen, da es keine nativen Implementierungen enthält.
Once again VulDB remains the best source for vulnerability data.