CWE-385

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-49092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-28T23:28:27Z",
    "nvd_published_at": "2023-11-28T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nDue to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.\n\n### Patches\nNo patch is yet available, however work is underway to migrate to a fully constant-time implementation.\n\n### Workarounds\nThe only currently available workaround is to avoid using the `rsa` crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.\n\n### References\nThis vulnerability was discovered as part of the \"Marvin Attack\", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.\n\n- https://rustsec.org/advisories/RUSTSEC-2023-0071.html\n- https://people.redhat.com/~hkario/marvin/\n- https://github.com/RustCrypto/RSA/issues/19",
  "id": "GHSA-c38w-74pg-36hr",
  "modified": "2026-04-27T16:45:08Z",
  "published": "2023-11-28T23:28:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/RSA/security/advisories/GHSA-c38w-74pg-36hr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49092"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/RSA/issues/19#issuecomment-1822995643"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/RSA/issues/626"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/RustCrypto/RSA"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2023-0071.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Marvin Attack: potential key recovery through timing sidechannels"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-49087"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-20T19:15:24Z",
    "severity": "MODERATE"
  },
  "details": "In Mbed TLS 3.6.1 through 3.6.3 before 3.6.4, a timing discrepancy in block cipher padding removal allows an attacker to recover the plaintext when PKCS#7 padding mode is used.",
  "id": "GHSA-fmjv-q9m9-j657",
  "modified": "2025-07-20T21:31:17Z",
  "published": "2025-07-20T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49087"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Mbed-TLS/mbedtls-docs/blob/main/security-advisories/mbedtls-security-advisory-2025-06-5.md"
    },
    {
      "type": "WEB",
      "url": "https://mbed-tls.readthedocs.io/en/latest/tech-updates/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/ausf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-208",
      "CWE-385",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T22:26:16Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe AUSF component of free5GC compares authentication response values with normal Go equality helpers instead of constant-time cryptographic comparison functions.\n\nTwo authentication flows are affected in `internal/sbi/processor/ue_authentication.go`:\n\n1. 5G-AKA confirmation compares `RES*` and `XRES*` with `strings.EqualFold()`.\n2. EAP-AKA\u0027 confirmation compares `AT_MAC` with `bytes.Equal()` and compares `XRES` and `RES` with `==`.\n\nThese functions are not designed to be constant-time cryptographic comparators and may return earlier depending on the location of the first mismatch.\n\nAdditionally, the 5G-AKA confirmation path logs both the received `res*` and the expected `Xres*` at INFO level immediately before comparing them. The `XRES*` value is authentication material and should not be written to application logs.\n\nThe timing side channel was confirmed as a code issue, but practical exploitation over HTTP was not demonstrated in the lab because the comparator-level signal is much smaller than HTTP/SBI noise. The `XRES*` logging issue is directly observable in AUSF logs.\n\nConfirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of the May 2026 analysis.\n\n### Details\n\n#### 5G-AKA: `RES*` / `XRES*`\n\nIn `Auth5gAkaComfirmRequestProcedure()`, the AUSF logs both values and then compares them with `strings.EqualFold()`:\n\n```go\n// internal/sbi/processor/ue_authentication.go\nlogger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\",\n    updateConfirmationData.ResStar, ausfCurrentContext.XresStar)\n\nif strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) {\n    ausfCurrentContext.AuthStatus = models.AusfUeAuthenticationAuthResult_SUCCESS\n    confirmDataRsp.AuthResult = models.AusfUeAuthenticationAuthResult_SUCCESS\n    success = true\n    logger.Auth5gAkaLog.Infoln(\"5G AKA confirmation succeeded\")\n    // ...\n}\n```\n\nFor hexadecimal ASCII strings, `strings.EqualFold()` performs a character comparison that can terminate when a mismatch is found. It is not a constant-time comparison primitive.\n\nThe line immediately before the comparison is more directly exploitable: it writes `XresStar` to INFO logs. Any operator, compromised sidecar, log collector, SIEM user, or local process with access to AUSF logs can read the expected response value for authentication attempts.\n\n#### EAP-AKA\u0027: `AT_MAC`, `XMAC`, `XRES`, and `RES`\n\nIn `EapAuthComfirmRequestProcedure()`, the AUSF computes the expected MAC and compares it with the received `AT_MAC` using `bytes.Equal()`:\n\n```go\nK_autStr := ausfCurrentContext.K_aut\nK_aut, _ := hex.DecodeString(K_autStr)\nXMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)\nMAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value\nXRES := ausfCurrentContext.XRES\nRES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)\n\nif !bytes.Equal(MAC, XMAC) {\n    eapOK = false\n    eapErrStr = \"EAP-AKA\u0027 integrity check fail\"\n} else if XRES == RES {\n    logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA\u0027 auth succeed\")\n    // ...\n}\n```\n\n`bytes.Equal()` is not specified as a constant-time cryptographic comparison. The subsequent `XRES == RES` string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is `crypto/subtle.ConstantTimeCompare`, after validating and normalizing input length and encoding.\n\nThe EAP-AKA\u0027 case is harder to exploit remotely than the 5G-AKA case because the `XRES == RES` comparison is reached only if `AT_MAC` is valid. Producing a valid `AT_MAC` requires session-specific `K_aut`.\n\n### Evidence\n\n#### Static evidence\n\nStatic analysis confirmed:\n\n- `strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar)` in the 5G-AKA confirmation path.\n- `logger.Auth5gAkaLog.Infof(\"res*: %x\\nXres*: %x\\n\", ...)` immediately before the comparison.\n- `bytes.Equal(MAC, XMAC)` in the EAP-AKA\u0027 confirmation path.\n- `XRES == RES` in the EAP-AKA\u0027 confirmation path.\n- `crypto/subtle` is absent from the AUSF authentication processor code.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/\n```\n\n#### 5G-AKA timing and logging evidence\n\nA timing PoC sent 500 iterations per condition over loopback HTTP/SBI:\n\n```text\nCondition A: mismatch near the start\nCondition B: mismatch in the middle\nCondition C: mismatch near the end\nCondition D: full match\n```\n\nThe comparator-position signal was not distinguishable from HTTP noise:\n\n```text\nDelta C-A: approximately -1.5 us\n2-sigma noise threshold: approximately 557 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance.\n\nThe same lab run confirmed that AUSF logs include `XresStar` in plaintext at INFO level. This does not require statistical inference.\n\nInternal evidence:\n\n```text\nhallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/\n```\n\n#### EAP-AKA\u0027 timing evidence\n\nA timing PoC sent 500 iterations per condition against the EAP-AKA\u0027 confirmation path:\n\n```text\nA: first MAC byte incorrect\nB: first 8 MAC bytes correct\nC: MAC correct, XRES incorrect\nD: MAC correct, XRES correct\n```\n\nObserved medians were all around 464-467 us, and the HTTP-level timing signal was not detectable:\n\n```text\nA: 466.6 us\nB: 466.5 us\nC: 464.2 us\nD: 464.2 us\nDelta D-A: approximately -2.4 us\n2-sigma noise threshold: approximately 716 us\nResult: SIGNAL NOT CLEAR\n```\n\nThis confirms the expected practical limitation of a remote HTTP timing attack.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/\n```\n\n#### Local CPU benchmark for `bytes.Equal()`\n\nA direct Go microbenchmark without HTTP overhead measured `bytes.Equal()` for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from `N=0` matching bytes to `N=15` matching bytes was roughly 0.31 ns, or more than 20%.\n\nThis confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/\n```\n\n#### Uprobe path confirmation\n\nLinux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths:\n\n- MAC comparison path is hit for both failing and successful EAP-AKA\u0027 attempts.\n- XRES comparison path is hit only when MAC verification passes.\n\nInternal evidence:\n\n```text\nhallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/\n```\n\n### Impact\n\nThere are two impact classes.\n\n#### Sensitive value in logs\n\nThe 5G-AKA path logs `XRES*`, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure.\n\nThe exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing `XRES*` to application logs is an unsafe handling of authentication material.\n\n#### Timing side channel / cryptographic hardening issue\n\nThe non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab.\n\nThe risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directly.\n\n### Suggested remediation\n\n1. Remove `XRES*`, `RES*`, `XRES`, `RES`, `K_aut`, `AT_MAC`, and derived authentication material from INFO logs. If logging is necessary, log only metadata such as the authentication context ID, SUPI/SUCI in redacted form, result, and failure class.\n\n2. Replace `strings.EqualFold()` and string `==` comparisons for authentication values with constant-time comparisons.\n\n3. Normalize encodings before comparison. For hex-encoded values, decode both inputs first, validate expected lengths, and then compare fixed-size byte slices.\n\nExample for 5G-AKA:\n\n```go\nresStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)\nxresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n    len(resStar) == len(xresStar) \u0026\u0026\n    subtle.ConstantTimeCompare(resStar, xresStar) == 1 {\n    // success\n} else {\n    // failure\n}\n```\n\nExample for EAP-AKA\u0027 MAC:\n\n```go\nif len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {\n    eapOK = false\n    eapErrStr = \"EAP-AKA\u0027 integrity check fail\"\n}\n```\n\nExample for EAP-AKA\u0027 XRES:\n\n```go\nres, err1 := hex.DecodeString(RES)\nxres, err2 := hex.DecodeString(XRES)\n\nif err1 == nil \u0026\u0026 err2 == nil \u0026\u0026\n    len(res) == len(xres) \u0026\u0026\n    subtle.ConstantTimeCompare(res, xres) == 1 {\n    // success\n}\n```\n\n4. Add unit tests that ensure authentication values are not written to logs.\n\n5. Consider avoiding a second UDM notification call in the 5G-AKA failure path if the first failure notification already reports the result. In the lab, failure performed two UDM calls while success performed one; this creates a coarse success/failure timing difference, although that result is already visible through the API response.\n\n### Prior art / non-duplication note\n\nKnown recent free5GC AUSF issues such as CVE-2026-33063 concern different failure modes and code paths. This report concerns cryptographic comparison and logging behavior in `internal/sbi/processor/ue_authentication.go`.",
  "id": "GHSA-fp46-6vfw-gc9c",
  "modified": "2026-08-28T22:26:16Z",
  "published": "2026-08-28T22:26:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-fp46-6vfw-gc9c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/ausf/commit/7a5a4aa1ec6cd0e1febebf333911c3104968edf0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-69893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-14T15:16:25Z",
    "severity": "MODERATE"
  },
  "details": "A side-channel vulnerability exists in the implementation of BIP-39 mnemonic processing, as observed in Trezor One v1.13.0 to v1.14.0, Trezor T v1.13.0 to v1.14.0, and Trezor Safe v1.13.0 to v1.14.0 hardware wallets. This originates from the BIP-39 standard guidelines, which induce non-constant time execution and specific branch patterns for word searching. An attacker with physical access during the initial setup phase can collect a single side-channel trace. By utilizing profiling-based Deep Learning Side-Channel Analysis (DL-SCA), the attacker can recover the mnemonic code and subsequently steal the assets. The issue was patched.",
  "id": "GHSA-fxwp-fxmc-jh57",
  "modified": "2026-04-16T15:31:30Z",
  "published": "2026-04-14T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69893"
    },
    {
      "type": "WEB",
      "url": "https://trezor.io/vulnerability/fix-side-channel-in-bip-39-mnemonic-processing-when-unlocked"
    },
    {
      "type": "WEB",
      "url": "http://trezor.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-3640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-24T16:15:13Z",
    "severity": "HIGH"
  },
  "details": "A possible unauthorized memory access flaw was found in the Linux kernel\u0027s cpu_entry_area mapping of X86 CPU data to memory, where a user may guess the location of exception stacks or other important data. Based on the previous CVE-2023-0597, the \u0027Randomize per-cpu entry area\u0027 feature was implemented in /arch/x86/mm/cpu_entry_area.c, which works through the init_cea_offsets() function when KASLR is enabled. However, despite this feature, there is still a risk of per-cpu entry area leaks. This issue could allow a local user to gain access to some important data with memory in an expected location and potentially escalate their privileges on the system.",
  "id": "GHSA-g854-mv2r-2r5h",
  "modified": "2025-04-15T12:30:24Z",
  "published": "2023-07-24T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3640"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:6583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-3640"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2217523"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-7396"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-18T23:15:23Z",
    "severity": "MODERATE"
  },
  "details": "In wolfSSL release 5.8.2 blinding support is turned on by default for Curve25519 in applicable builds. The blinding configure option is only for the base C implementation of Curve25519. It is not needed, or available with; ARM assembly builds, Intel assembly builds, and the small Curve25519 feature. While the side-channel attack on extracting a private key would be very difficult to execute in practice, enabling blinding provides an additional layer of protection for devices that may be more susceptible to physical access or side-channel observation.",
  "id": "GHSA-h9v3-wvxh-4mwp",
  "modified": "2025-12-03T15:30:27Z",
  "published": "2025-07-19T00:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7396"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/blob/master/ChangeLog.md#wolfssl-release-582-july-17-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:H/AT:P/PR:L/UI:A/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "cryptography"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-25659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-10-27T20:32:44Z",
    "nvd_published_at": "2021-01-11T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "RSA decryption was vulnerable to Bleichenbacher timing vulnerabilities, which would impact people using RSA decryption in online scenarios. This is fixed in cryptography 3.2. ",
  "id": "GHSA-hggm-jpg3-v476",
  "modified": "2024-11-18T16:26:10Z",
  "published": "2020-10-27T20:33:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyca/cryptography/security/advisories/GHSA-hggm-jpg3-v476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25659"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyca/cryptography/pull/5507"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyca/cryptography/commit/58494b41d6ecb0f56b7c5f05d5f5e3ca0320d494"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-hggm-jpg3-v476"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyca/cryptography"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/cryptography/PYSEC-2021-62.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/cryptography"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RSA decryption vulnerable to Bleichenbacher timing vulnerability"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypqc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.4"
            },
            {
              "last_affected": "0.0.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-385",
      "CWE-733"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-05T16:56:35Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n`kyber512`, `kyber768`, and `kyber1024` on Mac OS \\(or when compiled with clang\\) only: An attacker able to submit many decapsulation requests against a single private key, and to gain timing information about the decapsulation, could recover the private key. Proof-of-concept exploit exists for a local attacker.\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N/E:P/RL:U/RC:C  \n\n### Patches\nNo patch is currently available / pending upstream [PQClean#556](https://github.com/PQClean/PQClean/issues/556).\n\n### Workarounds\nNo workarounds have been reported. The 0.0.7 -\u003e 0.0.7.1 upgrade, when available, should be a drop-in replacement\u003c!--; it has no known breaking changes--\u003e.\n\n### References\n\nhttps://pqshield.com/pqshield-plugs-timing-leaks-in-kyber-ml-kem-to-improve-pqc-implementation-maturity/\n\nhttps://github.com/antoonpurnal/clangover\n\nhttps://www.github.com/PQClean/PQClean/issues/556\n\nhttps://www.github.com/pq-crystals/kyber/commit/9b8d30698a3e7449aeb34e62339d4176f11e3c6c",
  "id": "GHSA-hvh4-5qr6-3v7r",
  "modified": "2024-06-05T18:36:15Z",
  "published": "2024-06-05T16:56:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/JamesTheAwesomeDude/pypqc/security/advisories/GHSA-hvh4-5qr6-3v7r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PQClean/PQClean/issues/556"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/JamesTheAwesomeDude/pypqc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N/E:P/RL:U/RC:C",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Observable Timing Discrepancy in pypqc"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Devolutions.XTS.NET"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2024.11.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-11862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-27T19:01:01Z",
    "nvd_published_at": "2024-11-27T15:15:25Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nTiming attacks on Galois Field multiplications in this package. Successful exploitation would effectively allow a downgrade of the security guarantees of the XTS mode to the security guarantees of ECB mode, allowing block swapping, enabling identification of identical blocks, and rendering half of the XTS key obsolete. Timing attacks require specific conditions to be exploitable.\n\n### Patches\nPatched in 2024.11.26\n\n### Workarounds\nUpgrade the package\n\n### References\nhttps://en.wikipedia.org/wiki/Timing_attack\n",
  "id": "GHSA-j6vm-4r7g-x4gr",
  "modified": "2024-11-27T19:01:01Z",
  "published": "2024-11-27T19:01:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Devolutions/XTS.NET/security/advisories/GHSA-j6vm-4r7g-x4gr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11862"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Devolutions/XTS.NET/commit/fb349d5bfb587218e8603b38ea37f03f036b57fd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Devolutions/XTS.NET"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Devolutions.XTS.NET Vulnerable to Timing Attack on GF Multiplications"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-27587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-385"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-16T22:15:44Z",
    "severity": "MODERATE"
  },
  "details": "OpenSSL 3.0.0 through 3.3.2 on the PowerPC architecture is vulnerable to a Minerva attack, exploitable by measuring the time of signing of random messages using the EVP_DigestSign API, and then using the private key to extract the K value (nonce) from the signatures. Next, based on the bit size of the extracted nonce, one can compare the signing time of full-sized nonces to signatures that used smaller nonces, via statistical tests. There is a side-channel in the P-364 curve that allows private key extraction (also, there is a dependency between the bit size of K and the size of the side channel). NOTE: This CVE is disputed because the OpenSSL security policy explicitly notes that any side channels which require same physical system to be detected are outside of the threat model for the software. The timing signal is so small that it is infeasible to be detected without having the attacking process running on the same physical system.",
  "id": "GHSA-jqr3-3jm7-r6cm",
  "modified": "2025-06-26T18:31:19Z",
  "published": "2025-06-17T00:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27587"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/issues/24253"
    },
    {
      "type": "WEB",
      "url": "https://minerva.crocs.fi.muni.cz"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}