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.

91 vulnerabilities reference this CWE, most recent first.

GHSA-5379-F5HF-W38V

Vulnerability from github – Published: 2026-01-16 15:49 – Updated: 2026-01-16 15:49
VLAI
Summary
Deno node:crypto doesn't finalize cipher
Details

Summary

The vulnerability allows an attacker to have infinite encryptions.

This can lead to naive attempts at brute forcing, as well as more refined attacks with the goal to learn the server secrets.

PoC

import crypto from "node:crypto";

const key = crypto.randomBytes(32);
const iv = crypto.randomBytes(16);
const cipher = crypto.createCipheriv("aes-256-cbc", key, iv);
cipher.final()

console.log(cipher);

Expected Output

Cipheriv {
  _decoder: null,
  _options: undefined,
  Symbol(kHandle): CipherBase {}
}

Actual Output

Cipheriv {
  _events: {
    close: undefined,
    error: undefined,
    prefinish: [Function: prefinish],
    finish: undefined,
    drain: undefined,
    data: undefined,
    end: undefined,
    readable: undefined
  },
  _readableState: ReadableState {
    highWaterMark: 65536,
    buffer: [],
    bufferIndex: 0,
    length: 0,
    pipes: [],
    awaitDrainWriters: null,
    [Symbol(kState)]: 1048844
  },
  _writableState: WritableState {
    highWaterMark: 65536,
    length: 0,
    corked: 0,
    onwrite: [Function: bound onwrite],
    writelen: 0,
    bufferedIndex: 0,
    pendingcb: 0,
    [Symbol(kState)]: 17580812,
    [Symbol(kBufferedValue)]: null
  },
  allowHalfOpen: true,
  _final: [Function: final],
  _maxListeners: undefined,
  _transform: [Function: transform],
  _eventsCount: 1,
  [Symbol(kCapture)]: false,
  [Symbol(kCallback)]: null
}

Mitigations

All users should upgrade to Deno v2.6.0 or newer.

Severity
9.2 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.6"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "deno"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22863"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-16T15:49:35Z",
    "nvd_published_at": "2026-01-15T23:15:51Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nThe vulnerability allows an attacker to have infinite encryptions. \n\nThis can lead to naive attempts at brute forcing, as well as more refined attacks with the goal to learn the server secrets.\n\n### PoC\n```js\nimport crypto from \"node:crypto\";\n\nconst key = crypto.randomBytes(32);\nconst iv = crypto.randomBytes(16);\nconst cipher = crypto.createCipheriv(\"aes-256-cbc\", key, iv);\ncipher.final()\n\nconsole.log(cipher);\n```\n\n### Expected Output\n```js\nCipheriv {\n  _decoder: null,\n  _options: undefined,\n  Symbol(kHandle): CipherBase {}\n}\n```\n\n### Actual Output\n```js\nCipheriv {\n  _events: {\n    close: undefined,\n    error: undefined,\n    prefinish: [Function: prefinish],\n    finish: undefined,\n    drain: undefined,\n    data: undefined,\n    end: undefined,\n    readable: undefined\n  },\n  _readableState: ReadableState {\n    highWaterMark: 65536,\n    buffer: [],\n    bufferIndex: 0,\n    length: 0,\n    pipes: [],\n    awaitDrainWriters: null,\n    [Symbol(kState)]: 1048844\n  },\n  _writableState: WritableState {\n    highWaterMark: 65536,\n    length: 0,\n    corked: 0,\n    onwrite: [Function: bound onwrite],\n    writelen: 0,\n    bufferedIndex: 0,\n    pendingcb: 0,\n    [Symbol(kState)]: 17580812,\n    [Symbol(kBufferedValue)]: null\n  },\n  allowHalfOpen: true,\n  _final: [Function: final],\n  _maxListeners: undefined,\n  _transform: [Function: transform],\n  _eventsCount: 1,\n  [Symbol(kCapture)]: false,\n  [Symbol(kCallback)]: null\n}\n```\n\n### Mitigations\n\nAll users should upgrade to Deno v2.6.0 or newer.",
  "id": "GHSA-5379-f5hf-w38v",
  "modified": "2026-01-16T15:49:35Z",
  "published": "2026-01-16T15:49:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/security/advisories/GHSA-5379-f5hf-w38v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22863"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/denoland/deno"
    },
    {
      "type": "WEB",
      "url": "https://github.com/denoland/deno/releases/tag/v2.6.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Deno node:crypto doesn\u0027t finalize cipher"
}

GHSA-5544-C8GP-4P3X

Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 18:33
VLAI
Details

Windows Kerberos Information Disclosure Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-43547"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-08T18:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Windows Kerberos Information Disclosure Vulnerability",
  "id": "GHSA-5544-c8gp-4p3x",
  "modified": "2024-10-08T18:33:16Z",
  "published": "2024-10-08T18:33:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43547"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43547"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-78QR-24V5-7Q73

Vulnerability from github – Published: 2026-01-27 18:32 – Updated: 2026-05-12 15:31
VLAI
Details

Issue summary: When using the low-level OCB API directly with AES-NI or
other hardware-accelerated code paths, inputs whose length is not a multiple
of 16 bytes can leave the final partial block unencrypted and unauthenticated.

Impact summary: The trailing 1-15 bytes of a message may be exposed in
cleartext on encryption and are not covered by the authentication tag,
allowing an attacker to read or tamper with those bytes without detection.

The low-level OCB encrypt and decrypt routines in the hardware-accelerated
stream path process full 16-byte blocks but do not advance the input/output
pointers. The subsequent tail-handling code then operates on the original
base pointers, effectively reprocessing the beginning of the buffer while
leaving the actual trailing bytes unprocessed. The authentication checksum
also excludes the true tail bytes.

However, typical OpenSSL consumers using EVP are not affected because the
higher-level EVP and provider OCB implementations split inputs so that full
blocks and trailing partial blocks are processed in separate calls, avoiding
the problematic code path. Additionally, TLS does not use OCB ciphersuites.
The vulnerability only affects applications that call the low-level
CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with
non-block-aligned lengths in a single call on hardware-accelerated builds.
For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected
by this issue, as OCB mode is not a FIPS-approved algorithm.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-69418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-27T16:16:33Z",
    "severity": "MODERATE"
  },
  "details": "Issue summary: When using the low-level OCB API directly with AES-NI or\u003cbr\u003eother hardware-accelerated code paths, inputs whose length is not a multiple\u003cbr\u003eof 16 bytes can leave the final partial block unencrypted and unauthenticated.\u003cbr\u003e\u003cbr\u003eImpact summary: The trailing 1-15 bytes of a message may be exposed in\u003cbr\u003ecleartext on encryption and are not covered by the authentication tag,\u003cbr\u003eallowing an attacker to read or tamper with those bytes without detection.\u003cbr\u003e\u003cbr\u003eThe low-level OCB encrypt and decrypt routines in the hardware-accelerated\u003cbr\u003estream path process full 16-byte blocks but do not advance the input/output\u003cbr\u003epointers. The subsequent tail-handling code then operates on the original\u003cbr\u003ebase pointers, effectively reprocessing the beginning of the buffer while\u003cbr\u003eleaving the actual trailing bytes unprocessed. The authentication checksum\u003cbr\u003ealso excludes the true tail bytes.\u003cbr\u003e\u003cbr\u003eHowever, typical OpenSSL consumers using EVP are not affected because the\u003cbr\u003ehigher-level EVP and provider OCB implementations split inputs so that full\u003cbr\u003eblocks and trailing partial blocks are processed in separate calls, avoiding\u003cbr\u003ethe problematic code path. Additionally, TLS does not use OCB ciphersuites.\u003cbr\u003eThe vulnerability only affects applications that call the low-level\u003cbr\u003eCRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with\u003cbr\u003enon-block-aligned lengths in a single call on hardware-accelerated builds.\u003cbr\u003eFor these reasons the issue was assessed as Low severity.\u003cbr\u003e\u003cbr\u003eThe FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected\u003cbr\u003eby this issue, as OCB mode is not a FIPS-approved algorithm.\u003cbr\u003e\u003cbr\u003eOpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.\u003cbr\u003e\u003cbr\u003eOpenSSL 1.0.2 is not affected by this issue.",
  "id": "GHSA-78qr-24v5-7q73",
  "modified": "2026-05-12T15:31:13Z",
  "published": "2026-01-27T18:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69418"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/372fc5c77529695b05b4f5b5187691a57ef5dffc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/4016975d4469cd6b94927c607f7c511385f928d8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/52d23c86a54adab5ee9f80e48b242b52c4cc2347"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/a7589230356d908c0eca4b969ec4f62106f4f5ae"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/ed40856d7d4ba6cb42779b6770666a65f19cb977"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260127.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7PHF-QPM5-Q6P3

Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-10 09:31
VLAI
Details

Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) mishandle the authentication of AAD (Additional Authenticated Data) with an empty ciphertext allowing a forgery of such messages.

Impact summary: An attacker can forge empty messages with arbitrary AAD to the victim's application using these ciphers.

AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD modes: they accept a key, nonce, optional AAD (bytes that are authenticated but not encrypted), and plaintext, and produces ciphertext plus a 16-byte tag. On decrypt, EVP_DecryptFinal_ex() is documented to return success only if the tag is verified succesfully.

In OpenSSL's provider implementation of these ciphers, the expected tag is computed only when decryption function is invoked with non-empty data. If the caller supplies AAD and then calls EVP_DecryptFinal_ex() without invocation of the ciphertext update, which can happen when the received ciphertext length is zero, the tag is never recalculated and still holds its all-zeros value.

When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty ciphertext, and all-zeros tag passes authentication under any key they do not know, single-shot. When AES-SIV is used, for mounting the attack it's necessary for the application to reuse the decryption context without resetting the key.

AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since OpenSSL 3.2.

No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must implement their own protocol and use the EVP interface. Also they must skip the ciphertext update when a message with an empty ciphertext arrives.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as these algorithms are not FIPS approved and the affected code is outside the OpenSSL FIPS module boundary.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-45446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T17:17:19Z",
    "severity": "MODERATE"
  },
  "details": "Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV\n(RFC 8452) mishandle the authentication of AAD (Additional Authenticated\nData) with an empty ciphertext allowing a forgery of such messages.\n\nImpact summary: An attacker can forge empty messages with arbitrary AAD\nto the victim\u0027s application using these ciphers.\n\nAES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD\nmodes: they accept a key, nonce, optional AAD (bytes that are authenticated\nbut not encrypted), and plaintext, and produces ciphertext plus a 16-byte\ntag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only\nif the tag is verified succesfully.\n\nIn OpenSSL\u0027s provider implementation of these ciphers, the expected tag is\ncomputed only when decryption function is invoked with non-empty data.\nIf the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without\ninvocation of the ciphertext update, which can happen when the received\nciphertext length is zero, the tag is never recalculated and still holds its\nall-zeros value.\n\nWhen AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty\nciphertext, and all-zeros tag passes authentication under any key they do not\nknow, single-shot. When AES-SIV is used, for mounting the attack it\u0027s\nnecessary for the application to reuse the decryption context without\nresetting the key.\n\nAES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since\nOpenSSL 3.2.\n\nNo protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support\neither AES-GCM-SIV or AES-SIV. To mount an attack, the applications must\nimplement their own protocol and use the EVP interface. Also they must skip the\nciphertext update when a message with an empty ciphertext arrives.\n\nThe FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this\nissue, as these algorithms are not FIPS approved and the affected code is\noutside the OpenSSL FIPS module boundary.",
  "id": "GHSA-7phf-qpm5-q6p3",
  "modified": "2026-06-10T09:31:57Z",
  "published": "2026-06-09T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/25b32cd9d41d2bc01b6abc425bb4baf2c2236fdc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/71e2a5d263518cf5866043bd60ee4994d59e53a3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/7fe3f33a3b3a4c487aa4dcdbc87057f66ffd2b85"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/daca0f48e4a69a2892a62262bad59e62a8a76598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/eec5e9bf0d867333b8495e456f5235d225798a68"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/25b32cd9d41d2bc01b6abc425bb4baf2c2236fdc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/71e2a5d263518cf5866043bd60ee4994d59e53a3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/7fe3f33a3b3a4c487aa4dcdbc87057f66ffd2b85"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/daca0f48e4a69a2892a62262bad59e62a8a76598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/eec5e9bf0d867333b8495e456f5235d225798a68"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260609.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7QCX-4P32-QCMX

Vulnerability from github – Published: 2022-05-25 19:34 – Updated: 2022-06-08 18:04
VLAI
Summary
Missing Cryptographic Step in cassproject
Details

Impact

CaSS Library, (npm:cassproject) has a missing cryptographic step when storing cryptographic keys that can allow a server administrator access to an account’s cryptographic keys. This affects CaSS servers using standalone username/password authentication, which uses a method that expects e2e cryptographic security of authorization credentials.

Patches

The issue has been patched in 1.5.8, however, the vulnerable accounts are only resecured when the user next logs in using standalone authentication, as the data required to resecure the account is not available to the server.

Workarounds

The issue may be mitigated by using SSO or client side certificates to log in. Please note that SSO and client side certificate authentication does not have this expectation of no-knowledge credential access, and cryptographic keys are available to the server administrator.

References

There are no references at this time.

For more information

If you have any questions or comments about this advisory: * Open an issue in the CaSS Project Github * Email us at the CaSS Project

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "cassproject"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-25T19:34:20Z",
    "nvd_published_at": "2022-05-18T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nCaSS Library, (npm:cassproject) has a missing cryptographic step when storing cryptographic keys that can allow a server administrator access to an account\u2019s cryptographic keys. This affects CaSS servers using standalone username/password authentication, which uses a method that expects e2e cryptographic security of authorization credentials.\n\n### Patches\nThe issue has been patched in 1.5.8, however, the vulnerable accounts are only resecured when the user next logs in using standalone authentication, as the data required to resecure the account is not available to the server.\n\n### Workarounds\nThe issue may be mitigated by using SSO or client side certificates to log in. Please note that SSO and client side certificate authentication does not have this expectation of no-knowledge credential access, and cryptographic keys are available to the server administrator.\n\n### References\nThere are no references at this time.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the CaSS Project Github](https://github.com/cassproject/CASS/issues)\n* Email us at [the CaSS Project](mailto:cass@eduworks.com)\n\n",
  "id": "GHSA-7qcx-4p32-qcmx",
  "modified": "2022-06-08T18:04:47Z",
  "published": "2022-05-25T19:34:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cassproject/CASS/security/advisories/GHSA-7qcx-4p32-qcmx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29229"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cassproject/CASS"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cassproject/CASS/releases/tag/1.5.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing Cryptographic Step in cassproject"
}

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-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"
    }
  ]
}

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