Bouncy Castle for Java LTS: Offenlegung des AES-Schlüssels durch native Packet-Cipher
Zusammenfassung
Im Bouncy-Castle-for-Java-LTS-Build geben die nativen One-Shot-AES-Packet-Ciphers (AES-CBC, CCM, CFB, CTR, GCM und GCM-SIV) anstelle von Chiffretext den rohen AES-Schlüssel zurück, wenn dasselbe Java-Array als Eingabe und Ausgabe verwendet wird, etwa bei einer Verschlüsselung direkt über dem Schlüssel-Array. Die Länge der Ausgabe stimmt weiterhin, daher bemerkt die Anwendung den Fehler nicht. Ein Angreifer, der die Ausgabe abfangen oder einsehen kann, kann so den Schlüssel erlangen; dies setzt eine Anwendung voraus, die dieses Muster verwendet, und einen x86/x86-64-Prozessor mit aktivierter nativer Unterstützung.
Betroffen
- bcprov-lts (Bouncy Castle for Java LTS) ab 2.73.4 bis vor 2.73.13
- Nur auf x86/x86-64-Intel-Plattformen mit aktivierter nativer Unterstützung, Java 8 und neuer
- Nicht betroffen: bcprov (Bouncy Castle for Java ohne LTS), reine Java-Packet-Ciphers und Streaming-Native-Modi
Behoben in
- Behoben in BC-LTS 2.73.13
Umgehung
- Der Hersteller dokumentiert keinen Workaround; das Update auf 2.73.13 ist die Behebung.
- Nicht verifizierter Vorschlag: Dasselbe Array nicht gleichzeitig als Schlüssel, IV oder AAD und als Ausgabepuffer für native One-Shot-AES-Ciphers verwenden oder bis zum Update reine Java-Ciphers für diese Aufrufe einsetzen. Vorher testen.
Ausnutzung
- Keine Berichte über Ausnutzung in freier Wildbahn und kein öffentlicher Proof of Concept gefunden.
- CISA SSVC: Ausnutzung keine, automatisierbar nein, technische Auswirkung teilweise.
- EPSS 0.00253 (modellierte Schätzung, kein Nachweis für Ausnutzung).
Unsere Empfehlung
- Prüfen, ob bcprov-lts 2.73.4 bis 2.73.12 eingesetzt wird, etwa über Maven- oder Gradle-Abhängigkeitslisten, vom Hersteller gelieferte Java-Anwendungen oder eine Software-Stückliste (SBOM). Das reguläre bcprov ist nicht betroffen.
- bcprov-lts auf 2.73.13 aktualisieren.
- Eigenentwickelten Code prüfen, der direkt über Schlüssel-, IV- oder AAD-Arrays verschlüsselt, und nach dem Update die Ausgabe auf offengelegte Schlüssel kontrollieren.
- Bis zum Update das Muster der Verschlüsselung mit überlappenden Arrays in betroffenen Anwendungen vermeiden.
Öffentliche Exploits
In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.
Quellen der Recherche
- CVE-2026-71883 vendor wiki (Bouncy Castle) github.com
- Bouncy Castle LTS 2.73.13 release notes www.bouncycastle.org
- OSV entry CVE-2026-71883 osv.dev
- VulDB CVE-2026-71883 vuldb.com
- Keyfactor release notes for BC-LTS 2.73.13 support.keyfactor.com
Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 17:05.
Referenzen der NVD (1)
Quellen
Der Tracker verbindet offizielle, frei nutzbare Datenquellen – laufend aktualisiert:
- NVD (NIST) – CVE, Bewertung (CVSS), betroffene Produkte
- CISA KEV – von der CISA bestätigt aktiv ausgenutzte Lücken
- CISA Vulnrichment – Einschätzung der CISA (SSVC) im offiziellen CVE-Eintrag
- FIRST EPSS – Wahrscheinlichkeit einer Ausnutzung
- Microsoft MSRC – Patch Tuesday: Lücken, Schweregrad, Updates
- PoC-in-GitHub – öffentliche Proof-of-Concept-Repositories
- Metasploit (Rapid7) – Module des Metasploit Framework
- Exploit-DB (OffSec) – Archiv öffentlicher Exploits (nur Verweise)
- Patch-Tage: offizielle Seiten der Hersteller (je Hersteller verlinkt) (Patch-Tage der Hersteller)
Dieses Angebot nutzt Daten der NVD-API, ist aber von der NVD weder unterstützt noch zertifiziert. EPSS-Daten © FIRST.org.
Betroffen? Wir helfen.
Wir prüfen, ob Ihre Systeme betroffen sind, spielen Updates ein und schliessen die Lücke – auf Wunsch auch laufend mit dem System Health Checker.