CVE-2026-71885

In Bouncy Castle per Java prima della versione 1.86, l'implementazione di Messaging Layer Security (MLS, RFC 9420) non associava un credential X.509 alla signature_key di un LeafNode. La funzione LeafNode.verify() verificava la firma di un leaf contro la signature_key contenuta all’interno dello stesso leaf, mentre la catena di certificati X.509 del credential veniva memorizzata ma mai analizzata o validata, quindi la chiave pubblica del certificato end-entity non era mai richiesta di corrispondere alla signature_key come previsto dalla sezione 5.3 di RFC 9420. Di conseguenza, un attaccante poteva presentare il certificato di un’altra parte come proprio credential durante la firma del leaf, e il KeyPackage che lo racchiudeva, con una chiave non correlata, veniva accettato come identità dell’altra parte tramite KeyPackage.verify() e il percorso di validazione del leaf nel Group. In un deployment che consente commit esterni senza un controllo di ammissione del credential indipendente, un attaccante non autenticato poteva essere ammesso sotto l’identità X.509 di una vittima, espellerla (poiché le operazioni di resynchronization confrontano interamente i credential piuttosto che le chiavi di firma), derivare l’epoca corrente, decifrare i messaggi successivi del gruppo e inviare messaggi accettati come se provenissero dalla vittima. TreeKEM.LeafNode ora richiede che la public key del subject del certificato end-entity, codificata secondo lo schema di firma del cipher suite, sia uguale a signature_key per un credential X.509, e rifiuta il leaf altrimenti, inclusi chain vuoti o certificati con un tipo di chiave non compatibile con il cipher suite; la validazione della catena di certificati e dell’identità fino a un trust anchor rimane responsabilità dell’applicazione, come previsto dalla sezione 5.3.1 di RFC 9420. Le implementazioni che utilizzano solo credenziali di base non sono interessate da questa vulnerabilità.