V registru CVE přibylo ve dvou dnech patnáct záznamů o chybách Bouncy Castle

Projekt Bouncy Castle zapsal 2. a 3. října 2026 do registru CVE patnáct záznamů o chybách ve své kryptografické knihovně pro Javu. Opravené jsou všechny: patří k verzi 1.86 a k dlouhodobě podporované větvi LTS 2.73.13, které vyšly už v září. Nejvyšší známku dostala chyba v protokolu MLS, kvůli které mohl útočník vstoupit do šifrované skupiny pod cizí totožností.

Opravy vyšly v září, záznamy v registru až v říjnu

Balíček bcprov-jdk18on 1.86 leží na Maven Central s časovým razítkem 11. září 2026 a týž den uvádějí i poznámky k vydání. Oznámení na webu projektu je datované 15. zářím a jmenuje třináct čísel CVE. Větev LTS dostala verzi 2.73.13 deset dní po vydání 1.86, tedy 21. září.

Záznamy v registru CVE jsou ale až z 2. a 3. října. Přidělila si je Legion of the Bouncy Castle sama, u všech patnácti stojí jako autorita zkratka bcorg. Databáze hlášení GitHubu převzala 3. října dvanáct z nich a doplnila jim známky podle metodiky CVSS verze 4.

Samotné opravy byly v repozitáři vidět ještě dřív. Commit, který donutil MLS kontrolovat odstraňovaný list, je z 8. srpna, oprava kritické chyby z 18. srpna; obě podepsal David Hook. Záznamy v registru jsou tedy zhruba o tři týdny mladší než oprava, kterou popisují.

Kritická chyba: cizí certifikát jako doklad totožnosti

Jediný záznam se známkou 9,2 z deseti je CVE-2026-71885 a týká se protokolu Messaging Layer Security (RFC 9420), kterým se šifruje skupinová komunikace. Každého účastníka v něm zastupuje list stromu, struktura LeafNode: nese jeho podpisový klíč a doklad totožnosti. Když tím dokladem byl certifikát X.509, Bouncy Castle ho uložil, ale nikdy nerozebral. Nekontroloval tedy, že veřejný klíč koncového certifikátu odpovídá podpisovému klíči v listu, jak žádá oddíl 5.3 normy.

Útočník proto mohl předložit certifikát někoho jiného a list i obálku KeyPackage podepsat nesouvisejícím klíčem. Tam, kde nasazení pouští do skupiny takzvané externí commity a nemá vlastní kontrolu přijímaných dokladů, se mohl neověřený útočník dostat dovnitř pod totožností oběti, vyhodit ji ze skupiny, odvodit klíče běžící epochy, číst další zprávy a posílat vlastní, které ostatní přijmou jako její. Nová verze vyžaduje shodu klíčů a list s prázdným řetězcem certifikátů nebo s klíčem jiného typu odmítne. Ověření řetězce proti důvěryhodné kotvě zůstává na aplikaci a skupin, které používají jen základní doklad totožnosti, se chyba netýká.

Druhá chyba v MLS vyhodí ze skupiny kohokoli

Záznam CVE-2026-71890 se známkou 8,7 popisuje chybu o patro výš. Externí commit smí podle oddílu 12.2 RFC 9420 nést nejvýš jeden návrh na odstranění, kterým se příchozí zbavuje své vlastní starší položky ve stromu. Bouncy Castle počítal návrhy podle typu a hlídal, aby odstraňovaný index nevybočil z rozsahu, ale nikdy neověřil, že odstraňovaný list patří právě příchozímu. Kdo získal veřejnou strukturu GroupInfo, tedy přesně to, co externí účastník dostává, mohl odstranit libovolného člena a zabrat jeho místo. Kontrola dokladů, která tomu měla zabránit, existovala jen v testovací přípravě pro interoperabilitu, takže nechránila nikoho, kdo volal veřejné rozhraní.

Tři nálezy v OpenPGP

Nejpočetnější skupina se týká vysokoúrovňového rozhraní pro OpenPGP. Podle CVE-2026-71887 (8,2) podklíč, jehož vazební podpis neurčoval žádné příznaky použití, zdědil příznaky primárního klíče. Jedna část knihovny ho proto považovala za podpisový, druhá ne, a kvůli tomu se přeskočila křížová certifikace, kterou RFC 9580 u takového podklíče vyžaduje. Útočník mohl cizí veřejný podpisový podklíč navázat na vlastní primární klíč a nechat skutečné podpisy jeho majitele projít pod svým jménem. GnuPG tentýž certifikát odmítá jako nekřížově certifikovaný.

Blízko tomu je CVE-2026-71886 (8,2): knihovna uznala certifikaci cizí identity od kterékoli složky certifikátu, aniž by žádala příznak opravňující k certifikaci. Podepsat tak mohl i online podpisový podklíč, který právě pro tenhle případ příznak nemá.

Třetí nález se netýká podpisů, ale šifrování. Podle CVE-2026-85515 (8,2) prošla zkrácená zašifrovaná zpráva bez jediné chyby a na cestě SEIPD verze 1 se kontrola integrity neprovedla vůbec. Useknutí se přitom poznalo, jen se pak zahodilo: výjimka o chybějících datech se o patro výš četla jako čistý konec zprávy. Podepsaná a zašifrovaná zpráva se tak dala přečíst jako dobře utvořená nepodepsaná.

Kontrola jmenných omezení přeskakovala koncový certifikát

Mimo tyto dva okruhy stojí CVE-2026-71889 (8,7). Pomocná třída PKIXCertPathReviewer, která se používá k rozboru řetězce certifikátů, procházela při kontrole jmenných omezení celou cestu kromě její nulté položky. Tou je přitom koncový certifikát, takže se omezení podle oddílu 6.1.3 RFC 5280 na jeho jméno ani na alternativní jména nikdy nepoužila. Řetězec, který omezení vydávající autority porušoval, ohlásila třída jako platný s prázdným seznamem chyb, zatímco standardní validátor téhož poskytovatele tentýž řetězec proti téže kotvě zamítl.

Dva záznamy v oznámení nejsou

Seznam na stránce vydání jmenuje třináct čísel. V registru jsou ale k týmž verzím ještě dvě další, obě z 3. října. CVE-2026-97873 (5,3) popisuje starší rodiny odvození klíče z hesla, u kterých knihovna brala počet opakování z nedůvěryhodného vstupu bez horní meze, takže krátký vstup dokázal vynutit libovolně dlouhý výpočet. CVE-2026-71883 (8,2) se týká jen větve LTS a jejího nativního kódu pro šifrování paketů. Na stránce vydání 1.86 ani ve stránce k LTS 2.73.13 dnes ani jedno z těch čísel nestojí.

Které verze už chyby nemají

Opravené jsou Bouncy Castle for Java 1.86 a LTS 2.73.13. U varianty certifikované podle FIPS se čísla liší záznam od záznamu: u chyby ve jmenných omezeních uvádí registr jako opravené bcpkix-fips 1.0.13, 2.0.13 a 2.1.13, u useknutých zpráv OpenPGP verze 1.0.14, 2.0.14.1 a 2.1.14. Komu jde o konkrétní chybu, musí si tedy opravenou verzi dohledat u ní, ne v jednom seznamu.

Zbytek dávky míří na dva postkvantové algoritmy. U NTRU a HQC našel projekt místa, kde se s tajnými hodnotami počítalo způsobem závislým na jejich obsahu, takže měření času mohlo prozradit část soukromého klíče. Na rozdíl od chyb v MLS a OpenPGP je k tomu potřeba měřit běh na stejném stroji, takže je jejich dopad omezenější. Známky tomu odpovídají: 5,9 u HQC proti 9,2 u kritické chyby v MLS.

Zdroje

• New Release: Bouncy Castle Java 1.86, oznámení projektu, 15. září 2026
• Bouncy Castle Crypto Package – Release Notes, poznámky k vydání ve značce r1rv86
• bcprov-jdk18on 1.86 na Maven Central, časové razítko balíčku
• CVE-2026-71885, registr CVE, zveřejněno 3. října 2026
• GHSA-jch3-5j66-88vx, databáze hlášení GitHubu se známkou CVSS 4.0
• RFC 9420: The Messaging Layer Security (MLS) Protocol
• RFC 9580: OpenPGP