Eclipse KeyPont crypto11 EUVD-2026-110816

Exploitation requires two concrete preconditions tied to the PKCS#11 token model. First, the attacker must be able to open a session on the same token the victim uses and create a public object on it - the advisory states this can be an unauthenticated (public) session, so no login to the token is needed, but local/same-host reach to the token is (AV:L). Second, the victim application must use the affected lookup functions (FindMLKEMKeyPair, FindMLKEMKeyPairs, FindMLKEMKeyPairsWithAttributes) and then Encapsulate on a vulnerable version (2.0.0-rc3 through 2.0.0-rc8). A second, misconfiguration-driven path needs no planted object: if an ML-KEM private key has a CKA_LABEL but no CKA_ID and no public half with that label (deleted, renamed, or made by another tool), the 'ID only' fallback matches every ML-KEM public key and silently returns the first one the token lists. Limiting factors: attack is local to the token, confined to applications invoking the ML-KEM code path, and the v1 module paths have no ML-KEM support and are unaffected; giving ML-KEM keys a unique CKA_ID and looking them up by ID, and restricting who may open sessions on the token, constrain exploitation (per the advisory's stated workarounds).

All signals point to a moderate, conditional risk rather than an urgent one. The CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5) is internally consistent with the mechanism: AV:L reflects that the attacker must act against a token/HSM they can reach, PR:L reflects that they must be able to open a session on that token, and C:H/I:N/A:N matches an attack that recovers ML-KEM shared secrets (confidentiality) without tampering or denial of service. The vuln.today Decision label is 'this_month' - a prioritized-but-not-emergency signal consistent with the local attack vector and single-impact dimension. No EPSS score, no CISA KEV entry, and no SSVC automatable/exploitation fields were supplied; absence of these is not evidence either way, but there is no signal of active or widespread exploitation. The GHSA advisory includes a PoC section describing reproduction on SoftHSMv2 and SoftHSMv3, so a public PoC reference exists; it is not verified as working, distributable exploit code and must not be conflated with active exploitation. Net: this is a genuine cryptographic confidentiality flaw worth patching on a normal cadence, not a high-CVSS-but-illusory issue, but its real-world reach is bounded by the requirements that the attacker share access to the token and that the application use the affected ML-KEM lookup functions on a vulnerable release-candidate version.

On a shared PKCS#11 token, an attacker opens an unauthenticated (public) session and creates a CKK_ML_KEM public key object carrying the victim's CKA_ID/CKA_LABEL but containing the attacker's own encapsulation key. When the victim application calls FindMLKEMKeyPair*/Encapsulate, the lookup binds the attacker's public key (it is never verified against the private key), so the fresh shared secret is encrypted to the attacker, who then decapsulates and recovers it along with anything derived from it (e.g. via MLKEMDeriveKey). A public PoC reference describing this on SoftHSMv2/v3 exists; it is not verified as working exploit code.