CVE-2026-115408 in KeyPont
Riassunto
di VulDB • 27/10/2026
Nelle versioni `>= 2.0.0-rc3, <= 2.0.0-rc8` di `github.com/eclipse-keypont/crypto11/v2`, le funzioni di ricerca delle coppie di chiavi ML-KEM (`FindMLKEMKeyPair`, `FindMLKEMKeyPairs`, `FindMLKEMKeyPairsWithAttributes`) individuano la parte pubblica di una coppia di chiavi ML-KEM in base a `CKA_ID`/`CKA_LABEL` e non verificano mai tale chiave contro la chiave privata. Inoltre, la ricerca fallback "solo ID" viene eseguita anche quando la chiave privata non dispone di un `CKA_ID`, quindi il template della ricerca si riduce alla classe delle chiavi pubbliche e al tipo ML-KEM, restituendo la prima chiave pubblica ML-KEM presente sul token. La funzione `Encapsulate()` sulla coppia di chiavi risultante critta il segreto condiviso appena generato verso tale chiave; pertanto, è il proprietario (e non il detentore della chiave privata cercata dall'utente) a poter recuperare il segreto. Un attaccante in grado di aprire una sessione non autenticata sul token e di inserire un oggetto pubblico `CKK_ML_KEM` recante l'id (`CKA_ID`) o l'etichetta (`CKA_LABEL`) della vittima, riceve i segreti condivisi per le operazioni di encapsulation eseguite tramite la coppia di chiavi sostituita, compromettendo la riservatezza di tali segreti e di tutto ciò che è protetto da chiavi derivate da essi. I percorsi dei moduli v1 non supportano ML-KEM e non sono interessati dalla vulnerabilità.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.