<!--This ticket is confidential.--> <!--############################# Do not remove the lines above #############################--> # CVE Reservation Request <!--There's help in the Eclipse Foundation Project Handbook https://www.eclipse.org/projects/handbook/#vulnerability-cve Note that this issue is configured (see the quick actions at the bottom) to be created as confidential. Note that a vulnerability does not need to actually be resolved before it is reported and that these reports can be revised as needed (reopen the issue to request changes). If you do not know how to fill certain fields, mark that in the comment and we will help you. You can delete the comments (or not).--> The Eclipse Foundation is a [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE) Numbering Authority. Creating this ticket initiates **reservation** of a CVE ID for the documented vulnerability. The reserved CVE ID will be posted in a comment below, and kept **confidential** until explicit publication request. > [!note] > > To request CVE _publication_, please open a [CVE publication](https://gitlab.eclipse.org/security/cve-assignment/-/issues/new?issuable_template=CVE%20Publication%20Request&issue%5Bconfidential%5D=true) ticket. Please fill in the fields below to draft the CVE record. --- ## CVE record information **Project name:** Eclipse KeyPont crypto11 **Project id:** `technology.keypont` > [!note] > > Project `crypto11` is on GitHub: https://github.com/eclipse-keypont/crypto11 Corresponding GitHub Security Advisory: https://github.com/eclipse-keypont/crypto11/security/advisories/GHSA-7842-qc22-qh4x **Versions affected:** > [!note] > > crypto11 is a Golang project. `pkg.go.dev` uses the GitHub name as go package name. ML-KEM support exists only on the v2 line, from v2.0.0-rc3 (the first v2 tag); the v1 module paths have no ML-KEM support and are not affected. | Package Name | Affected versions | Patched versions | |--------------|-------------------|------------------| | github.com/eclipse-keypont/crypto11/v2 | \>= 2.0.0-rc3, \<= 2.0.0-rc8 | \>= 2.0.0-rc9 | **Common Weakness Enumeration (CWE):** - [CWE-345](https://cwe.mitre.org/data/definitions/345.html) **Common Attack Pattern Enumerations and Classifications (CAPEC):** - I do not have one. **Common Vulnerability Scoring System:** `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` **Summary:** 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. **Links:** - GitHub Security Advisory: https://github.com/eclipse-keypont/crypto11/security/advisories/GHSA-7842-qc22-qh4x - Fix: https://github.com/eclipse-keypont/crypto11/commit/8d99b73c721c173ad85c0ca4e063c3da360a611d **Credits:** Eclipse Foundation Security Team