All vulnerabilities
CVE-2026-115408GHSA-7842-qc22-qh4x

Eclipse KeyPont: ML-KEM key-pair lookup can bind an unrelated or attacker-planted public key, exposing encapsulated shared secrets

Eclipse Foundation Eclipse KeyPont
CVSS
5.5Medium
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)No scoreNo FIRST EPSS score in this snapshot yet
Fixed inNone listedNo source names a fixed version. Check the vendor advisory below
Published27 Oct 2026Updated 27 Oct 2026CVE List

What fixes it

No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.

Description

In github.com/eclipse-keypont/crypto11/v2 versions >= 2.0.0-rc3, <= 2.0.0-rc8, the ML-KEM key-pair lookup functions (FindMLKEMKeyPair, FindMLKEMKeyPairs, FindMLKEMKeyPairsWithAttributes) locate the public half of an ML-KEM key pair by CKA_ID/CKA_LABEL and never verify it against the private key. In addition, the "ID only" fallback search runs even when the private key has no CKA_ID, so the search template reduces to the public-key class and the ML-KEM key type and the first ML-KEM public key on the token is returned. Encapsulate() on the resulting key pair encrypts the fresh shared secret to that key, so its owner — not the holder of the private key the caller looked up — can recover the secret. An attacker who can open an unauthenticated session on the token and plant a public CKK_ML_KEM object carrying the victim's CKA_ID/CKA_LABEL receives the shared secrets for encapsulations performed through the substituted key pair, compromising the confidentiality of those secrets and of everything protected by keys derived from them. The v1 module paths have no ML-KEM support and are not affected.

Text from CVE List

Affected versions 1

  • Eclipse KeyPontaffected: 2.0.0-rc3 through 2.0.0-rc8CVE List

References 3