In Eclipse KeyPont library versions 2.0.0‑rc3 through 2.0.0‑rc8, the ML‑KEM key‑pair lookup functions locate a public key by CKA_ID or CKA_LABEL but do not confirm it is paired with the corresponding private key. When the private key lacks an ID, the lookup falls back to a template that matches only the public‑key class and the ML‑KEM type, causing the first ML‑KEM public key on the token to be returned. Encapsulate operations on the mistakenly returned key encrypt a fresh shared secret to that key, allowing the holder of the planted public key to recover the secret. An attacker who can open an unauthenticated session on the token and implant a public CKK_ML_KEM object with a victim’s ID or label can obtain all shared secrets encapsulated through the substituted key pair, compromising confidentiality of those secrets and any data derived from them.

The vulnerability affects the Eclipse KeyPont product from the Eclipse Foundation. Affected releases are the 2.x series, specifically any version from 2.0.0‑rc3 up to and including 2.0.0‑rc8. The 1.x series, which has no ML‑KEM support, is not impacted.

The CVSS score is 5.5, indicating a moderate severity. No EPSS score is available, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector requires an unauthenticated session capable of creating or modifying public key objects on the token; an attacker must therefore have some level of 0‑day or privileged access to the appliance or the token handling process. Because no exploitation reports exist, the exploitation likelihood is uncertain, but the ability to obtain shared secrets presents a significant confidentiality risk if the conditions are met.