Search

Find a vulnerability

Search criteria

    2 vulnerabilities found for Eclipse KeyPont by Eclipse Foundation

    CVE-2026-115408 (GCVE-0-2026-115408)

    Vulnerability from nvd – Published: 2026-10-27 11:55 – Updated: 2026-10-27 11:55
    VLAI
    Title
    ML-KEM key-pair lookup can bind an unrelated or attacker-planted public key, exposing encapsulated shared secrets
    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.
    Severity
    5.5 (Medium)
    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
    CWE
    Assigner
    eclipse CNA under the mitre root
    CNA scorecard C 64/100 over 190 records in the last 180 days details
    References
    Impacted products
    Vendor Product Version
    Eclipse Foundation Eclipse KeyPont Affected: 2.0.0-rc3 , ≤ 2.0.0-rc8 (semver)
    		Create a notification for this product.
    Show details on NVD website
    To clipboard 

    {
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "crypto11",
          "product": "Eclipse KeyPont",
          "vendor": "Eclipse Foundation",
          "versions": [
            {
              "lessThanOrEqual": "2.0.0-rc8",
              "status": "affected",
              "version": "2.0.0-rc3",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eIn `github.com/eclipse-keypont/crypto11/v2` versions `\u0026gt;= 2.0.0-rc3, \u0026lt;= 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 \u2014 not the holder of the private key the caller looked up \u2014 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\u0027s `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.\u003c/p\u003e"
            }
          ],
          "value": "In `github.com/eclipse-keypont/crypto11/v2` versions `\u003e= 2.0.0-rc3, \u003c= 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 \u2014 not the holder of the private key the caller looked up \u2014 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\u0027s `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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 5.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T11:55:15.600Z",
        "orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
        "shortName": "eclipse"
      },
      "references": [
        {
          "url": "https://github.com/eclipse-keypont/crypto11/security/advisories/GHSA-7842-qc22-qh4x"
        },
        {
          "url": "https://github.com/eclipse-keypont/crypto11/commit/8d99b73c721c173ad85c0ca4e063c3da360a611d"
        },
        {
          "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/490"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "ML-KEM key-pair lookup can bind an unrelated or attacker-planted public key, exposing encapsulated shared secrets",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
    "assignerShortName": "eclipse",
    "cveId": "CVE-2026-115408",
    "datePublished": "2026-10-27T11:55:15.600Z",
    "dateReserved": "2026-10-22T11:56:53.145Z",
    "dateUpdated": "2026-10-27T11:55:15.600Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

    CVE-2026-115408 (GCVE-0-2026-115408)

    Vulnerability from cvelistv5 – Published: 2026-10-27 11:55 – Updated: 2026-10-27 11:55
    VLAI
    Title
    ML-KEM key-pair lookup can bind an unrelated or attacker-planted public key, exposing encapsulated shared secrets
    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.
    Severity
    5.5 (Medium)
    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
    CWE
    Assigner
    eclipse CNA under the mitre root
    CNA scorecard C 64/100 over 190 records in the last 180 days details
    References
    Impacted products
    Vendor Product Version
    Eclipse Foundation Eclipse KeyPont Affected: 2.0.0-rc3 , ≤ 2.0.0-rc8 (semver)
    		Create a notification for this product.
    Show details on NVD website
    To clipboard 

    {
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "crypto11",
          "product": "Eclipse KeyPont",
          "vendor": "Eclipse Foundation",
          "versions": [
            {
              "lessThanOrEqual": "2.0.0-rc8",
              "status": "affected",
              "version": "2.0.0-rc3",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eIn `github.com/eclipse-keypont/crypto11/v2` versions `\u0026gt;= 2.0.0-rc3, \u0026lt;= 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 \u2014 not the holder of the private key the caller looked up \u2014 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\u0027s `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.\u003c/p\u003e"
            }
          ],
          "value": "In `github.com/eclipse-keypont/crypto11/v2` versions `\u003e= 2.0.0-rc3, \u003c= 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 \u2014 not the holder of the private key the caller looked up \u2014 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\u0027s `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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 5.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T11:55:15.600Z",
        "orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
        "shortName": "eclipse"
      },
      "references": [
        {
          "url": "https://github.com/eclipse-keypont/crypto11/security/advisories/GHSA-7842-qc22-qh4x"
        },
        {
          "url": "https://github.com/eclipse-keypont/crypto11/commit/8d99b73c721c173ad85c0ca4e063c3da360a611d"
        },
        {
          "url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/490"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "ML-KEM key-pair lookup can bind an unrelated or attacker-planted public key, exposing encapsulated shared secrets",
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
    "assignerShortName": "eclipse",
    "cveId": "CVE-2026-115408",
    "datePublished": "2026-10-27T11:55:15.600Z",
    "dateReserved": "2026-10-22T11:56:53.145Z",
    "dateUpdated": "2026-10-27T11:55:15.600Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}