Common Weakness Enumeration

CWE-325

Allowed

Missing Cryptographic Step

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

99 vulnerabilities reference this CWE, most recent first.

GHSA-9PV8-QFVR-2QXM

Vulnerability from github – Published: 2025-11-11 18:30 – Updated: 2025-11-11 18:30
VLAI
Details

Missing cryptographic step in Windows Kerberos allows an unauthorized attacker to elevate privileges over a network.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-60704"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T18:15:38Z",
    "severity": "HIGH"
  },
  "details": "Missing cryptographic step in Windows Kerberos allows an unauthorized attacker to elevate privileges over a network.",
  "id": "GHSA-9pv8-qfvr-2qxm",
  "modified": "2025-11-11T18:30:21Z",
  "published": "2025-11-11T18:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60704"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-60704"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XG4-QHM4-G43W

Vulnerability from github – Published: 2026-06-16 19:08 – Updated: 2026-06-16 19:08
VLAI
Summary
Deno: Miller-Rabin Primality Test Allows Zero Rounds
Details

Summary

node:crypto.checkPrime(candidate[, options][, callback]) and crypto.checkPrimeSync(candidate[, options]) ran no Miller-Rabin rounds at all when the caller left options.checks at its default of 0. In that mode, the only test applied to the candidate was trial division by the primes up to 17,863. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as 17,881 × 17,891 — was reported as true ("probably prime").

The same divergence affected the lower-level op_node_check_prime / op_node_check_prime_bytes paths that the polyfill calls into.

Node.js itself does not have this problem: it forwards checks = 0 to OpenSSL's BN_check_prime, which substitutes a sensible default number of rounds based on the candidate's bit length (per FIPS 186-4 Appendix C.3 Table C.1). Deno's Rust implementation had no equivalent fallback, so count = 0 meant "skip the loop entirely."

Affected APIs

  • crypto.checkPrime(candidate) (callback form, default options)
  • crypto.checkPrime(candidate, { checks: 0 }, callback)
  • crypto.checkPrimeSync(candidate) (default options)
  • crypto.checkPrimeSync(candidate, { checks: 0 })

Callers who explicitly passed checks >= 1 were less affected, the loop ran the number of rounds they asked for, but were still receiving fewer rounds than Node would have applied for the same bit length. With the patched version they get at least the FIPS minimum.

Not affected

  • Deno's prime generation (crypto.generatePrime, crypto.generatePrimeSync, and the DH parameter generation path). Those routes go through Prime::generate_with_options in ext/node_crypto/primes.rs, which hardcodes 20 Miller-Rabin rounds and never reads a user-controlled checks value, so the bug never reached them.
  • Any other Deno-internal use of primality testing — is_probably_prime is not called from elsewhere in the runtime with count = 0.
  • Web Crypto (crypto.subtle.*), which uses entirely separate code paths and does not expose a primality test.

Impact

The realistic exposure is application-level: a Deno program that calls crypto.checkPrime (or its sync variant) with default options to validate an externally-supplied bignum, for example checking a peer-provided Diffie-Hellman prime, validating a prime read from configuration, or sanity-checking an RSA factor, will accept crafted composites as prime. The composite is trivial to construct: any product of two primes greater than 17,863 works.

Downstream consequences depend on what the program does with the "verified" prime. If the prime is fed into a key exchange, signature verification, or factorization-style check, the security guarantees of that protocol collapse to whatever the attacker engineered into the composite.

The CVSS impact is bounded by the requirement that the victim application both (a) calls checkPrime with default options and (b) acts on the result for security-relevant input it does not control.

Reproduction

import { checkPrimeSync } from "node:crypto";

// 17881 and 17891 are both prime and both above the trial-division
// ceiling used by Deno's implementation.
const composite = 17881n * 17891n;

// Affected versions print `true`; the patched version prints `false`.
console.log(checkPrimeSync(composite));

The same result is reproducible from Rust against the internal helper:

use num_bigint::BigInt;
let composite = BigInt::from(17881u32) * BigInt::from(17891u32);
assert!(!is_probably_prime(&composite, 0)); // fails on affected versions

Fix

PR #34391 introduces a helper min_miller_rabin_rounds_for_bits(bits) that returns the FIPS 186-4 Appendix C.3 round counts, matching the defaults OpenSSL uses inside BN_check_prime. is_probably_prime then clamps the loop bound to count.max(min_miller_rabin_rounds_for_bits(n.bits())). The probabilistic loop now always executes, regardless of what checks value the caller supplied, with a round count strong enough to keep the false-positive probability below 2^-80. Callers that pass a larger explicit checks still get exactly that many rounds.

Unit tests under ext/node_crypto/primes.rs cover the 17,881 × 17,891 case, a larger 64-bit composite, and the FIPS lookup table itself.

Workarounds

If you cannot upgrade immediately:

  • Pass an explicit checks value when calling crypto.checkPrime or crypto.checkPrimeSync. A value of 64 is conservative for any reasonable bit length and keeps the loop running.
  • Do not rely on crypto.checkPrime to validate attacker-influenced bignums in security-critical paths until you are on the patched release.
Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.8.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T19:08:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`node:crypto.checkPrime(candidate[, options][, callback])` and `crypto.checkPrimeSync(candidate[, options])` ran no Miller-Rabin rounds at all when the caller left `options.checks` at its default of `0`. In that mode, the only test applied to the candidate was trial division by the primes up to `17,863`. Any composite whose smallest prime factor exceeds that bound \u2014 for example the product of two primes just above it, such as `17,881 \u00d7 17,891` \u2014 was reported as `true` (\"probably prime\").\n\nThe same divergence affected the lower-level `op_node_check_prime` / `op_node_check_prime_bytes` paths that the polyfill calls into.\n\nNode.js itself does not have this problem: it forwards `checks = 0` to OpenSSL\u0027s `BN_check_prime`, which substitutes a sensible default number of rounds based on the candidate\u0027s bit length (per FIPS 186-4 Appendix C.3 Table C.1). Deno\u0027s Rust implementation had no equivalent fallback, so `count = 0` meant \"skip the loop entirely.\"\n\n## Affected APIs\n\n- `crypto.checkPrime(candidate)` (callback form, default options)\n- `crypto.checkPrime(candidate, { checks: 0 }, callback)`\n- `crypto.checkPrimeSync(candidate)` (default options)\n- `crypto.checkPrimeSync(candidate, { checks: 0 })`\n\nCallers who explicitly passed `checks \u003e= 1` were less affected, the loop ran the number of rounds they asked for, but were still receiving fewer rounds than Node would have applied for the same bit length. With the patched version they get at least the FIPS minimum.\n\n## Not affected\n\n- Deno\u0027s prime *generation* (`crypto.generatePrime`, `crypto.generatePrimeSync`, and the DH parameter generation path). Those routes go through `Prime::generate_with_options` in `ext/node_crypto/primes.rs`, which hardcodes `20` Miller-Rabin rounds and never reads a user-controlled `checks` value, so the bug never reached them.\n- Any other Deno-internal use of primality testing \u2014 `is_probably_prime` is not called from elsewhere in the runtime with `count = 0`. \n- Web Crypto (`crypto.subtle.*`), which uses entirely separate code paths and does not expose a primality test.\n\n## Impact\n\nThe realistic exposure is application-level: a Deno program that calls `crypto.checkPrime` (or its sync variant) with default options to validate an externally-supplied bignum, for example checking a peer-provided Diffie-Hellman prime, validating a prime read from configuration, or sanity-checking an RSA factor, will accept crafted composites as prime. The composite is trivial to construct: any product of two primes greater than `17,863` works.\n\nDownstream consequences depend on what the program does with the \"verified\" prime. If the prime is fed into a key exchange, signature verification, or factorization-style check, the security guarantees of that protocol collapse to whatever the attacker engineered into the composite.\n\nThe CVSS impact is bounded by the requirement that the victim application both (a) calls `checkPrime` with default options and (b) acts on the result for security-relevant input it does not control.\n\n## Reproduction\n\n```ts\nimport { checkPrimeSync } from \"node:crypto\";\n\n// 17881 and 17891 are both prime and both above the trial-division\n// ceiling used by Deno\u0027s implementation.\nconst composite = 17881n * 17891n;\n\n// Affected versions print `true`; the patched version prints `false`.\nconsole.log(checkPrimeSync(composite));\n```\n\nThe same result is reproducible from Rust against the internal helper:\n\n```rust\nuse num_bigint::BigInt;\nlet composite = BigInt::from(17881u32) * BigInt::from(17891u32);\nassert!(!is_probably_prime(\u0026composite, 0)); // fails on affected versions\n```\n\n## Fix\n\nPR [#34391](https://github.com/denoland/deno/pull/34391) introduces a\nhelper `min_miller_rabin_rounds_for_bits(bits)` that returns the FIPS\n186-4 Appendix C.3 round counts, matching the defaults OpenSSL uses\ninside `BN_check_prime`. `is_probably_prime` then clamps the loop bound\nto `count.max(min_miller_rabin_rounds_for_bits(n.bits()))`. The\nprobabilistic loop now always executes, regardless of what `checks`\nvalue the caller supplied, with a round count strong enough to keep the\nfalse-positive probability below 2^-80. Callers that pass a larger\nexplicit `checks` still get exactly that many rounds.\n\nUnit tests under `ext/node_crypto/primes.rs` cover the\n`17,881 \u00d7 17,891` case, a larger 64-bit composite, and the FIPS lookup\ntable itself.\n\n## Workarounds\n\nIf you cannot upgrade immediately:\n\n- **Pass an explicit `checks` value** when calling `crypto.checkPrime` or `crypto.checkPrimeSync`. A value of `64` is conservative for any reasonable bit length and keeps the loop running.\n- **Do not rely on `crypto.checkPrime` to validate attacker-influenced bignums** in security-critical paths until you are on the patched release.",
  "id": "GHSA-9xg4-qhm4-g43w",
  "modified": "2026-06-16T19:08:55Z",
  "published": "2026-06-16T19:08:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-9xg4-qhm4-g43w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/pull/34391"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Deno: Miller-Rabin Primality Test Allows Zero Rounds"
}

GHSA-CQJX-GWFH-QHM2

Vulnerability from github – Published: 2026-07-30 03:31 – Updated: 2026-07-30 21:31
VLAI
Details

Cryptographic Flaw in Enterprise in Google Chrome prior to 151.0.7922.72 allowed an attacker in a privileged network position to bypass discretionary access control via malicious network traffic. (Chromium security severity: High)

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-17666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T01:16:28Z",
    "severity": "CRITICAL"
  },
  "details": "Cryptographic Flaw in Enterprise in Google Chrome prior to 151.0.7922.72 allowed an attacker in a privileged network position to bypass discretionary access control via malicious network traffic. (Chromium security severity: High)",
  "id": "GHSA-cqjx-gwfh-qhm2",
  "modified": "2026-07-30T21:31:32Z",
  "published": "2026-07-30T03:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17666"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/511761758"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CW6W-5W44-CCRQ

Vulnerability from github – Published: 2023-11-15 00:31 – Updated: 2024-09-19 15:30
VLAI
Details

Cryptographic issues with In-Meeting Chat for some Zoom clients may allow a privileged user to conduct an information disclosure via network access.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-39199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T23:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Cryptographic issues with In-Meeting Chat for some Zoom clients may allow a privileged user to conduct an information disclosure via network access.",
  "id": "GHSA-cw6w-5w44-ccrq",
  "modified": "2024-09-19T15:30:47Z",
  "published": "2023-11-15T00:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39199"
    },
    {
      "type": "WEB",
      "url": "https://explore.zoom.us/en/trust/security/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G9P5-P7H5-P2WG

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2025-12-03 15:30
VLAI
Details

Libgcrypt before 1.8.8 and 1.9.x before 1.9.3 mishandles ElGamal encryption because it lacks exponent blinding to address a side-channel attack against mpi_powm, and the window size is not chosen appropriately. (There is also an interoperability problem because the selection of the k integer value does not properly consider the differences between basic ElGamal encryption and generalized ElGamal encryption.) This, for example, affects use of ElGamal in OpenPGP.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-33560"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203",
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-08T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "Libgcrypt before 1.8.8 and 1.9.x before 1.9.3 mishandles ElGamal encryption because it lacks exponent blinding to address a side-channel attack against mpi_powm, and the window size is not chosen appropriately. (There is also an interoperability problem because the selection of the k integer value does not properly consider the differences between basic ElGamal encryption and generalized ElGamal encryption.) This, for example, affects use of ElGamal in OpenPGP.",
  "id": "GHSA-g9p5-p7h5-p2wg",
  "modified": "2025-12-03T15:30:27Z",
  "published": "2022-05-24T19:04:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33560"
    },
    {
      "type": "WEB",
      "url": "https://dev.gnupg.org/T5305"
    },
    {
      "type": "WEB",
      "url": "https://dev.gnupg.org/T5328"
    },
    {
      "type": "WEB",
      "url": "https://dev.gnupg.org/T5466"
    },
    {
      "type": "WEB",
      "url": "https://dev.gnupg.org/rCe8b7f10be275bcedb5fc05ed4837a89bfd605c61"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00021.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BKKTOIGFW2SGN3DO2UHHVZ7MJSYN4AAB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/R7OAPCUGPF3VLA7QAJUQSL255D4ITVTL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BKKTOIGFW2SGN3DO2UHHVZ7MJSYN4AAB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/R7OAPCUGPF3VLA7QAJUQSL255D4ITVTL"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202210-13"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GV8J-3J98-685G

Vulnerability from github – Published: 2025-06-29 21:30 – Updated: 2025-06-29 21:30
VLAI
Details

RLPx 5 has two CTR streams based on the same key, IV, and nonce. This can facilitate decryption on a private network.

Severity
3.4 (Low)
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2015-20112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-29T21:15:22Z",
    "severity": "LOW"
  },
  "details": "RLPx 5 has two CTR streams based on the same key, IV, and nonce. This can facilitate decryption on a private network.",
  "id": "GHSA-gv8j-3j98-685g",
  "modified": "2025-06-29T21:30:26Z",
  "published": "2025-06-29T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-20112"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethereum/devp2p/issues/32"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethereum/go-ethereum/issues/1315"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperledger/besu/issues/7926"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LaurentMT/go-ethereum/commit/e8cba7283b57280b1bcf5761478f852398365901"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethereum/devp2p/blob/master/rlpx.md#known-issues-in-the-current-version"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H2WP-QQPW-35J4

Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32
VLAI
Details

Missing cryptographic step in Windows Boot Loader allows an authorized attacker to bypass a security feature locally.

Severity
6.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-58638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T18:18:46Z",
    "severity": "MODERATE"
  },
  "details": "Missing cryptographic step in Windows Boot Loader allows an authorized attacker to bypass a security feature locally.",
  "id": "GHSA-h2wp-qqpw-35j4",
  "modified": "2026-07-14T18:32:42Z",
  "published": "2026-07-14T18:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58638"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-58638"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H63V-HW6G-X8HP

Vulnerability from github – Published: 2024-12-09 21:31 – Updated: 2024-12-11 21:35
VLAI
Summary
Bit flip attack vulnerability in cookie-encrypter
Details

due to a weakness in the encryption method used in cookie-encrypter an attack can use the world visible IV to edit encrypted cookies without decrypting the cookie itself. This is known as an AES CBC bit flipping attack.

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "cookie-encrypter"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-53441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325",
      "CWE-327"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-11T21:35:13Z",
    "nvd_published_at": "2024-12-09T20:15:20Z",
    "severity": "HIGH"
  },
  "details": "due to a weakness in the encryption method used in cookie-encrypter an attack can use the world visible IV to edit encrypted cookies without decrypting the cookie itself. This is known as an AES CBC bit flipping attack.",
  "id": "GHSA-h63v-hw6g-x8hp",
  "modified": "2024-12-11T21:35:13Z",
  "published": "2024-12-09T21:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ebourmalo/cookie-encrypter/issues/9"
    },
    {
      "type": "WEB",
      "url": "https://crypto.stackexchange.com/questions/66085/bit-flipping-attack-on-cbc-mode"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/mathysEthical/f45f1503f87381090e38a33c50eec971"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ebourmalo/cookie-encrypter"
    },
    {
      "type": "WEB",
      "url": "https://mathys.reboux.pro/CVE/2024/53441"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Bit flip attack vulnerability in cookie-encrypter"
}

GHSA-HCRG-QR57-HR37

Vulnerability from github – Published: 2025-05-22 15:34 – Updated: 2025-06-04 21:31
VLAI
Details

Missing Cryptographic Step vulnerability in Tridium Niagara Framework on Windows, Linux, QNX, Tridium Niagara Enterprise Security on Windows, Linux, QNX allows Cryptanalysis. This issue affects Niagara Framework: before 4.14.2, before 4.15.1, before 4.10.11; Niagara Enterprise Security: before 4.14.2, before 4.15.1, before 4.10.11. Tridium recommends upgrading to Niagara Framework and Enterprise Security versions 4.14.2u2, 4.15.u1, or 4.10u.11.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-3938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325",
      "CWE-327"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-22T13:15:56Z",
    "severity": "MODERATE"
  },
  "details": "Missing Cryptographic Step vulnerability in Tridium Niagara Framework on Windows, Linux, QNX, Tridium Niagara Enterprise Security on Windows, Linux, QNX allows Cryptanalysis. This issue affects Niagara Framework: before 4.14.2, before 4.15.1, before 4.10.11; Niagara Enterprise Security: before 4.14.2, before 4.15.1, before 4.10.11.\u00a0Tridium recommends upgrading to Niagara Framework and Enterprise Security versions 4.14.2u2, 4.15.u1, or 4.10u.11.",
  "id": "GHSA-hcrg-qr57-hr37",
  "modified": "2025-06-04T21:31:09Z",
  "published": "2025-05-22T15:34:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3938"
    },
    {
      "type": "WEB",
      "url": "https://docs.niagara-community.com/category/tech_bull"
    },
    {
      "type": "WEB",
      "url": "https://www.honeywell.com/us/en/product-security#security-notices"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HGW8-7XF9-389H

Vulnerability from github – Published: 2025-05-29 18:31 – Updated: 2025-05-29 18:31
VLAI
Details

A vulnerability, which was classified as problematic, has been found in fossasia open-event-server 1.19.1. This issue affects the function send_email_change_user_email of the file /fossasia/open-event-server/blob/development/app/api/helpers/mail.py of the component Mail Verification Handler. The manipulation leads to reliance on obfuscation or encryption of security-relevant inputs without integrity checking. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-5323"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-29T18:15:24Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as problematic, has been found in fossasia open-event-server 1.19.1. This issue affects the function send_email_change_user_email of the file /fossasia/open-event-server/blob/development/app/api/helpers/mail.py of the component Mail Verification Handler. The manipulation leads to reliance on obfuscation or encryption of security-relevant inputs without integrity checking. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-hgw8-7xf9-389h",
  "modified": "2025-05-29T18:31:20Z",
  "published": "2025-05-29T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5323"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/superboy-zjc/31ecea91b304b8dd9871ad507467ca61"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/superboy-zjc/31ecea91b304b8dd9871ad507467ca61#proof-of-concept"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.310493"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.310493"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.580256"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/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"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-68: Subvert Code-signing Facilities

Many languages use code signing facilities to vouch for code's identity and to thus tie code to its assigned privileges within an environment. Subverting this mechanism can be instrumental in an attacker escalating privilege. Any means of subverting the way that a virtual machine enforces code signing classifies for this style of attack.

← Back to the CWE list