CVE-2026-17507 in Bouncy Castle Java
Riassunto
di VulDB • 03/10/2026
In Bouncy Castle per Java prima della versione 1.86, l'implementazione di MLS (org.bouncycastle.mls) memorizza il valore uint32 leaf_index definito da RFC 9420 in un int con segno; pertanto, un valore sul filo (wire value) con il bit più significativo impostato viene decodificato come numero negativo. Si tratta di una codifica legittima e non di input malformato, che deve comunque essere decodificata correttamente poiché i vettori di test per l'interoperabilità MLS effettuano round-trip sull'intero intervallo di valori. I metodi GroupKeySet.SecretTree.hasLeaf e Group.validateRemove confrontavano il valore decodificato direttamente con il numero di foglie (leaf count) dell'albero; un confronto tra interi con segno considera qualsiasi int negativo come inferiore a un limite positivo, consentendo così a un mittente fuori range di superare il controllo di appartenenza al gruppo. Nel caso del metodo hasLeaf, i dati del mittente (SenderData) di un PrivateMessage non protetto potevano quindi far sì che LeafIndex.directPath attraversasse l'aritmetica di NodeIndex.parent() senza mai raggiungere la radice dell'albero, facendo crescere indefinitamente la lista dei nodi risultanti fino all'esaurimento della heap della JVM. Un singolo messaggio piccolo inviato da qualsiasi membro corrente del gruppo poteva pertanto causare un denial of service (DoS) per tutti gli altri membri del gruppo. Entrambi i confronti ora interpretano il valore come non firmato tramite Integer.toUnsignedLong, rifiutando un mittente fuori range indipendentemente dalla sua codifica; le leaf indices ben formate rimangono invariate.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.