Common Weakness Enumeration

CWE-325

Allowed

Missing Cryptographic Step

Abstraction: Base · Status: Draft

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-P8VH-85VC-66X9

Vulnerability from github – Published: 2022-06-03 00:01 – Updated: 2024-03-27 15:30
VLAI
Details

Using its HSTS support, curl can be instructed to use HTTPS directly insteadof using an insecure clear-text HTTP step even when HTTP is provided in theURL. This mechanism could be bypassed if the host name in the given URL used atrailing dot while not using one when it built the HSTS cache. Or the otherway around - by having the trailing dot in the HSTS cache and not using thetrailing dot in the URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-30115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319",
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-02T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Using its HSTS support, curl can be instructed to use HTTPS directly insteadof using an insecure clear-text HTTP step even when HTTP is provided in theURL. This mechanism could be bypassed if the host name in the given URL used atrailing dot while not using one when it built the HSTS cache. Or the otherway around - by having the trailing dot in the HSTS cache and *not* using thetrailing dot in the URL.",
  "id": "GHSA-p8vh-85vc-66x9",
  "modified": "2024-03-27T15:30:35Z",
  "published": "2022-06-03T00:01:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30115"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1557449"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202212-01"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220609-0009"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/10/26/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/12/21/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QC34-RVRG-F2Q8

Vulnerability from github – Published: 2022-12-26 06:30 – Updated: 2023-01-05 21:30
VLAI
Details

Certain General Electric Renewable Energy products have inadequate encryption strength. This affects iNET and iNET II before 8.3.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-24116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325",
      "CWE-326"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-26T05:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Certain General Electric Renewable Energy products have inadequate encryption strength. This affects iNET and iNET II before 8.3.0.",
  "id": "GHSA-qc34-rvrg-f2q8",
  "modified": "2023-01-05T21:30:16Z",
  "published": "2022-12-26T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24116"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-090-06"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R3GF-C2CF-VP8Q

Vulnerability from github – Published: 2025-07-04 15:31 – Updated: 2025-07-04 15:31
VLAI
Details

In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator to bypass verification.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-49600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-04T15:15:22Z",
    "severity": "MODERATE"
  },
  "details": "In MbedTLS 3.3.0 before 3.6.4, mbedtls_lms_verify may accept invalid signatures if hash computation fails and internal errors go unchecked, enabling LMS (Leighton-Micali Signature) forgery in a fault scenario. Specifically, unchecked return values in mbedtls_lms_verify allow an attacker (who can induce a hardware hash accelerator fault) to bypass LMS signature verification by reusing stale stack data, resulting in acceptance of an invalid signature. In mbedtls_lms_verify, the return values of the internal Merkle tree functions create_merkle_leaf_value and create_merkle_internal_value are not checked. These functions return an integer that indicates whether the call succeeded or not. If a failure occurs, the output buffer (Tc_candidate_root_node) may remain uninitialized, and the result of the signature verification is unpredictable. When the software implementation of SHA-256 is used, these functions will not fail. However, with hardware-accelerated hashing, an attacker could use fault injection against the accelerator to bypass verification.",
  "id": "GHSA-r3gf-c2cf-vp8q",
  "modified": "2025-07-04T15:31:10Z",
  "published": "2025-07-04T15:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49600"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Mbed-TLS/mbedtls-docs/blob/main/security-advisories/mbedtls-security-advisory-2025-06-3.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R6FJ-869H-4F6Q

Vulnerability from github – Published: 2026-06-23 21:59 – Updated: 2026-06-23 21:59
VLAI
Summary
OHttpVersionChunkDraft: Missing Final-Chunk Enforcement Leads to Undetected Stream Truncation
Details

The codec-ohttp implementation of draft-ietf-ohai-chunked-ohttp does not verify that a cryptographically-signed final chunk was received before the outer HTTP body terminates. An on-path adversary (the OHTTP relay itself, or any MITM on the relay↔gateway or relay↔client transport) can forward a prefix of a legitimate chunked-OHTTP message—cut at a non-final chunk boundary—and close the outer body cleanly, producing no decryption error and no exception in the receiving application.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty.incubator:netty-incubator-codec-ohttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.22.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T21:59:03Z",
    "nvd_published_at": "2026-06-04T19:16:30Z",
    "severity": "MODERATE"
  },
  "details": "The codec-ohttp implementation of draft-ietf-ohai-chunked-ohttp does not verify that a cryptographically-signed final chunk was received before the outer HTTP body terminates. An on-path adversary (the OHTTP relay itself, or any MITM on the relay\u2194gateway or relay\u2194client transport) can forward a prefix of a legitimate chunked-OHTTP message\u2014cut at a non-final chunk boundary\u2014and close the outer body cleanly, producing no decryption error and no exception in the receiving application.",
  "id": "GHSA-r6fj-869h-4f6q",
  "modified": "2026-06-23T21:59:03Z",
  "published": "2026-06-23T21:59:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp/security/advisories/GHSA-r6fj-869h-4f6q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp/commit/28f977f293591a4e837bd59ceb441f9f70349915"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty-incubator-codec-ohttp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OHttpVersionChunkDraft: Missing Final-Chunk Enforcement Leads to Undetected Stream Truncation"
}

GHSA-V446-XWFM-X7MR

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

Issue summary: When an application drives an AES-OCB context through the public EVP_Cipher() one-shot interface, the application-supplied initialisation vector (IV) is silently discarded.

Impact summary: Every message encrypted under the same key uses the same effective nonce regardless of the IV supplied by the caller, resulting in (key, nonce) reuse and loss of confidentiality. If the same code path is used to compute the authentication tag, the tag depends only on the (key, IV) pair and not on the plaintext or ciphertext, allowing universal forgery of arbitrary ciphertext from a single captured message.

OpenSSL provides two ways to drive a cipher: the documented streaming interface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level one-shot, EVP_Cipher(), whose documentation explicitly recommends against use by applications in favour of EVP_CipherUpdate() and EVP_CipherFinal_ex(). The OCB provider's streaming handler flushes the application-supplied IV into the OCB context before processing data; the one-shot handler did not. Every call to EVP_Cipher() on an AES-OCB context therefore ran with the all-zero key-derived offset state left by cipher initialisation, regardless of the caller's IV.

If EVP_EncryptFinal_ex() is subsequently used to obtain the authentication tag, the deferred IV setup runs at that point and clears the running checksum that should have been accumulated over the plaintext. The resulting tag is a function of (key, IV) only and verifies against any ciphertext produced under the same (key, IV) pair.

The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a TLS cipher suite, and libssl does not call EVP_Cipher() in any case. Applications that drive AES-OCB through the documented streaming AEAD API (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Only applications that combine the AES-OCB cipher with the EVP_Cipher() one-shot API are vulnerable.

The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by this issue, as AES-OCB is outside the OpenSSL FIPS module boundary.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-45445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T17:17:18Z",
    "severity": "HIGH"
  },
  "details": "Issue summary: When an application drives an AES-OCB context through the\npublic EVP_Cipher() one-shot interface, the application-supplied\ninitialisation vector (IV) is silently discarded.\n\nImpact summary: Every message encrypted under the same key uses the\nsame effective nonce regardless of the IV supplied by the caller,\nresulting in (key, nonce) reuse and loss of confidentiality.  If the\nsame code path is used to compute the authentication tag, the tag\ndepends only on the (key, IV) pair and not on the plaintext or\nciphertext, allowing universal forgery of arbitrary ciphertext from a\nsingle captured message.\n\nOpenSSL provides two ways to drive a cipher: the documented streaming\ninterface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level\none-shot, EVP_Cipher(), whose documentation explicitly recommends\nagainst use by applications in favour of EVP_CipherUpdate() and\nEVP_CipherFinal_ex().  The OCB provider\u0027s streaming handler flushes\nthe application-supplied IV into the OCB context before processing\ndata; the one-shot handler did not.  Every call to EVP_Cipher() on an\nAES-OCB context therefore ran with the all-zero key-derived offset\nstate left by cipher initialisation, regardless of the caller\u0027s IV.\n\nIf EVP_EncryptFinal_ex() is subsequently used to obtain the\nauthentication tag, the deferred IV setup runs at that point and\nclears the running checksum that should have been accumulated over the\nplaintext.  The resulting tag is a function of (key, IV) only and\nverifies against any ciphertext produced under the same (key, IV)\npair.\n\nThe OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a\nTLS cipher suite, and libssl does not call EVP_Cipher() in any case.\nApplications that drive AES-OCB through the documented streaming AEAD\nAPI (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected.  Only\napplications that combine the AES-OCB cipher with the EVP_Cipher()\none-shot API are vulnerable.\n\nThe FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by\nthis issue, as AES-OCB is outside the OpenSSL FIPS module boundary.",
  "id": "GHSA-v446-xwfm-x7mr",
  "modified": "2026-06-10T09:31:57Z",
  "published": "2026-06-09T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/323f0b6e7d530a4cb4336d50c88cb70f3ac2a451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/787a6dfba81b7b09c1e05ab31396c0cd7c36b3f7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/7ac4715234ee72d9f3c93426a2c08554b5b771af"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/843c9b94ca9c2ed248bb30127bb4f3d7af0d607c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/983d54b5cce8d16147548ed1a37892d1720bbab6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/323f0b6e7d530a4cb4336d50c88cb70f3ac2a451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/787a6dfba81b7b09c1e05ab31396c0cd7c36b3f7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/7ac4715234ee72d9f3c93426a2c08554b5b771af"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/843c9b94ca9c2ed248bb30127bb4f3d7af0d607c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/983d54b5cce8d16147548ed1a37892d1720bbab6"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260609.txt"
    }
  ],
  "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-VQ8W-MHC4-P67J

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:58
VLAI
Details

RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-3738"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-18T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.",
  "id": "GHSA-vq8w-mhc4-p67j",
  "modified": "2024-04-04T01:58:26Z",
  "published": "2022-05-24T16:56:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3738"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10318"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/security/en-us/details/DOC-106556/DSA-2019-094-RSA-BSAFE\u0026#174%3B-Crypto-J-Multiple-Security-Vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/security/en-us/details/DOC-106556/DSA-2019-094-RSA-BSAFE\u0026#174;-Crypto-J-Multiple-Security-Vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2020.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:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VWW4-R7GR-9XVQ

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

An improper implementation of TLS certificate validation vulnerability found in ReadyCloud client app which can allow an attacker to perform attacker-in-the-middle (MiTM) style attacks impacting product's confidentiality. This vulnerability affects the listed NETGEAR models.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0420"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T17:17:00Z",
    "severity": "MODERATE"
  },
  "details": "An improper implementation of TLS certificate validation vulnerability found in ReadyCloud client app which can allow an attacker to perform\u00a0attacker-in-the-middle (MiTM) style attacks impacting product\u0027s confidentiality. This vulnerability affects the listed NETGEAR models.",
  "id": "GHSA-vww4-r7gr-9xvq",
  "modified": "2026-06-18T18:35:17Z",
  "published": "2026-06-09T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0420"
    },
    {
      "type": "WEB",
      "url": "https://kb.netgear.com/000070811/June-2026-NETGEAR-Security-Advisory"
    },
    {
      "type": "WEB",
      "url": "https://www.netgear.com/support/product/rax120v2"
    },
    {
      "type": "WEB",
      "url": "https://www.netgear.com/support/product/rax35"
    },
    {
      "type": "WEB",
      "url": "https://www.netgear.com/support/product/rax38"
    },
    {
      "type": "WEB",
      "url": "https://www.netgear.com/support/product/rax40"
    }
  ],
  "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:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U/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"
    }
  ]
}

GHSA-W4WV-5X8M-W2CF

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

A vulnerability in pairing process of Cisco TelePresence CE Software and RoomOS Software for Cisco Touch 10 Devices could allow an unauthenticated, remote attacker to impersonate a legitimate device and pair with an affected device. This vulnerability is due to insufficient identity verification. An attacker could exploit this vulnerability by impersonating a legitimate device and responding to the pairing broadcast from an affected device. A successful exploit could allow the attacker to access the affected device while impersonating a legitimate device.There are no workarounds that address this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20793"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-15T16:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in pairing process of Cisco\u0026nbsp;TelePresence CE Software and RoomOS Software for Cisco\u0026nbsp;Touch 10 Devices could allow an unauthenticated, remote attacker to impersonate a legitimate device and pair with an affected device.\nThis vulnerability is due to insufficient identity verification. An attacker could exploit this vulnerability by impersonating a legitimate device and responding to the pairing broadcast from an affected device. A successful exploit could allow the attacker to access the affected device while impersonating a legitimate device.There are no workarounds that address this vulnerability.",
  "id": "GHSA-w4wv-5x8m-w2cf",
  "modified": "2024-11-15T18:30:49Z",
  "published": "2024-11-15T18:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20793"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-CTT-IVV-4A66Dsfj"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W8Q8-93CX-6H7R

Vulnerability from github – Published: 2026-03-23 06:30 – Updated: 2026-03-29 15:51
VLAI
Summary
jsrsasign: Missing cryptographic validation during DSA signing enables private key extraction
Details

Versions of the package jsrsasign before 11.1.1 are vulnerable to Missing Cryptographic Step via the KJUR.crypto.DSA.signWithMessageHash process in the DSA signing implementation. An attacker can recover the private key by forcing r or s to be zero, so the library emits an invalid signature without retrying, and then solves for x from the resulting signature.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jsrsasign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-4601"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:51:59Z",
    "nvd_published_at": "2026-03-23T06:16:21Z",
    "severity": "HIGH"
  },
  "details": "Versions of the package jsrsasign before 11.1.1 are vulnerable to Missing Cryptographic Step via the KJUR.crypto.DSA.signWithMessageHash process in the DSA signing implementation. An attacker can recover the private key by forcing r or s to be zero, so the library emits an invalid signature without retrying, and then solves for x from the resulting signature.",
  "id": "GHSA-w8q8-93cx-6h7r",
  "modified": "2026-03-29T15:51:59Z",
  "published": "2026-03-23T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4601"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/pull/645"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/commit/0710e392ec35de697ce11e4219c988ba2b5fe0eb"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Kr0emer/93789fe6efe5519db9692d4ad1dad586"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kjur/jsrsasign"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-JSRSASIGN-15370941"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:H/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jsrsasign: Missing cryptographic validation during DSA signing enables private key extraction"
}

GHSA-WGQ8-VR6R-MQXM

Vulnerability from github – Published: 2025-09-03 21:29 – Updated: 2025-09-05 16:11
VLAI
Summary
frost-core: refresh shares with smaller min_signers will reduce security of group
Details

Impact

It was not clear that it is not possible to change min_signers (i.e. the threshold) with the refresh share functionality (frost_core::keys::refresh module). Using a smaller value would not decrease the threshold, and attempts to sign using a smaller threshold would fail. Additionally, after refreshing the shares with a smaller threshold, it would still be possible to sign with the original threshold; however, this could cause a security loss to the participant's shares. We have not determined the exact security implications of doing so and judged simpler to just validate min_signers.

If for some reason you have done a refresh share procedure with a smaller min_signers we strongly recommend migrating to a new key.

Patches

Updating to 2.2.0 will ensure that the min_signers parameter will be validated. However it won't restore the security of groups refreshed with a smaller min_signers parameters.

Workarounds

You don't need to update if you don't use the refresh share functionality, or if you didn't try to change the min_signers parameter using the refresh share functionality.

References

Thank you BlockSec for reporting the finding

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "frost-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-325"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-03T21:29:18Z",
    "nvd_published_at": "2025-09-05T00:15:32Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIt was not clear that it is not possible to change `min_signers` (i.e. the threshold) with the refresh share functionality (`frost_core::keys::refresh` module). Using a smaller value would not decrease the threshold, and attempts to sign using a smaller threshold would fail. Additionally, after refreshing the shares with a smaller threshold, it would still be possible to sign with the original threshold; however, this could cause a security loss to the participant\u0027s shares. We have not determined the exact security implications of doing so and judged simpler to just validate `min_signers`. \n\n If for some reason you have done a refresh share procedure with a smaller `min_signers` we strongly recommend migrating to a new key. \n\n### Patches\n\nUpdating to 2.2.0 will ensure that the `min_signers` parameter will be validated. However it won\u0027t restore the security of groups refreshed with a smaller `min_signers` parameters.\n\n### Workarounds\n\nYou don\u0027t need to update if you don\u0027t use the refresh share functionality, or if you didn\u0027t try to change the `min_signers` parameter using the refresh share functionality.\n\n### References\n\nThank you [BlockSec](https://blocksec.com/) for reporting the finding",
  "id": "GHSA-wgq8-vr6r-mqxm",
  "modified": "2025-09-05T16:11:20Z",
  "published": "2025-09-03T21:29:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/frost/security/advisories/GHSA-wgq8-vr6r-mqxm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58359"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/frost/commit/379ef689c733b3d9c80fd409071d4f3af4dafed2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/frost"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/frost/releases/tag/frost-core%2Fv2.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "frost-core: refresh shares with smaller min_signers will reduce security of group"
}

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.