CWE-1240
AllowedUse of a Cryptographic Primitive with a Risky Implementation
Abstraction: Base · Status: Draft
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.
42 vulnerabilities reference this CWE, most recent first.
GHSA-7M29-F4HW-G2VX
Vulnerability from github – Published: 2026-02-18 22:33 – Updated: 2026-02-27 20:37There is a fingerprint mismatch with Chrome when using GREASE ECH, having to do with ciphersuite selection. When Chrome selects the preferred ciphersuite in the outer ClientHello and the ciphersuite for ECH, it does so consistently based on hardware support. That means, for example, if it prefers AES for the outer ciphersuite, it would also use AES for ECH. The Chrome parrot in utls hardcodes AES preference for outer ciphersuites but selects the ECH ciphersuite randomly between AES and ChaCha20. So there is a 50% chance of selecting ChaCha20 for ECH while using AES for the outer ciphersuite, which is impossible in Chrome.
This is only a problem in GREASE ECH, since in real ECH Chrome selects the first valid ciphersuite when AES is preferred, which is the same in utls. So no change is done there.
Affected symbols: HelloChrome_120, HelloChrome_120_PQ, HelloChrome_131, HelloChrome_133
Fix commit: 24bd1e05a788c1add7f3037f4532ea552b2cee07
Thanks to telegram @acgdaily for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/refraction-networking/utls"
},
"ranges": [
{
"events": [
{
"introduced": "1.6.0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27017"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-18T22:33:18Z",
"nvd_published_at": "2026-02-20T03:16:01Z",
"severity": "LOW"
},
"details": "There is a fingerprint mismatch with Chrome when using GREASE ECH, having to do with ciphersuite selection. When Chrome selects the preferred ciphersuite in the outer ClientHello and the ciphersuite for ECH, it does so consistently based on hardware support. That means, for example, if it prefers AES for the outer ciphersuite, it would also use AES for ECH. The Chrome parrot in utls hardcodes AES preference for outer ciphersuites but selects the ECH ciphersuite randomly between AES and ChaCha20. So there is a 50% chance of selecting ChaCha20 for ECH while using AES for the outer ciphersuite, which is impossible in Chrome.\n\nThis is only a problem in GREASE ECH, since in real ECH Chrome selects the first valid ciphersuite when AES is preferred, which is the same in utls. So no change is done there.\n\nAffected symbols: `HelloChrome_120`, `HelloChrome_120_PQ`, `HelloChrome_131`, `HelloChrome_133`\n\nFix commit: 24bd1e05a788c1add7f3037f4532ea552b2cee07\n\nThanks to telegram @acgdaily for reporting this issue.",
"id": "GHSA-7m29-f4hw-g2vx",
"modified": "2026-02-27T20:37:32Z",
"published": "2026-02-18T22:33:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/refraction-networking/utls/security/advisories/GHSA-7m29-f4hw-g2vx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27017"
},
{
"type": "WEB",
"url": "https://github.com/refraction-networking/utls/commit/24bd1e05a788c1add7f3037f4532ea552b2cee07"
},
{
"type": "PACKAGE",
"url": "https://github.com/refraction-networking/utls"
},
{
"type": "WEB",
"url": "https://github.com/refraction-networking/utls/releases/tag/v1.8.1"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-4509"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "uTLS has a fingerprint vulnerability from GREASE ECH mismatch for Chrome parrots"
}
GHSA-8457-MXPV-X45G
Vulnerability from github – Published: 2025-02-03 15:32 – Updated: 2025-02-03 15:32Dell Key Trust Platform, v3.0.6 and prior, contains Use of a Cryptographic Primitive with a Risky Implementation vulnerability. A local privileged attacker could potentially exploit this vulnerability, leading to privileged information disclosure.
{
"affected": [],
"aliases": [
"CVE-2024-37137"
],
"database_specific": {
"cwe_ids": [
"CWE-1240",
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-28T02:15:03Z",
"severity": "MODERATE"
},
"details": "Dell Key Trust Platform, v3.0.6 and prior, contains Use of a Cryptographic Primitive with a Risky Implementation vulnerability. A local privileged attacker could potentially exploit this vulnerability, leading to privileged information disclosure.",
"id": "GHSA-8457-mxpv-x45g",
"modified": "2025-02-03T15:32:00Z",
"published": "2025-02-03T15:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37137"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000226476/dsa-2024-294-security-update-for-dell-cloudlink-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-848J-6MX2-7J84
Vulnerability from github – Published: 2026-01-08 21:30 – Updated: 2026-01-09 20:19The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which can lead to secret key exposure. This happens, because the byte-length of 'k' is incorrectly computed, resulting in its getting truncated during the computation. Legitimate transactions or communications will be broken as a result. Furthermore, due to the nature of the fault, attackers could–under certain conditions–derive the secret key, if they could get their hands on both a faulty signature generated by a vulnerable version of Elliptic and a correct signature for the same inputs.
This issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "elliptic"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "6.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-14505"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-09T20:19:43Z",
"nvd_published_at": "2026-01-08T21:15:42Z",
"severity": "LOW"
},
"details": "The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of \u0027k\u0027 (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which can lead to secret key exposure. This happens, because the byte-length of \u0027k\u0027 is incorrectly computed, resulting in its getting truncated during the computation. Legitimate transactions or communications will be broken as a result.\u00a0Furthermore, due to the nature of the fault, attackers could\u2013under certain conditions\u2013derive the secret key, if they could get their hands on both a faulty signature generated by a vulnerable version of Elliptic and a correct signature for the same inputs.\n\nThis issue affects all known versions of Elliptic (at the time of writing, versions less than or equal to 6.6.1).",
"id": "GHSA-848j-6mx2-7j84",
"modified": "2026-01-09T20:19:43Z",
"published": "2026-01-08T21:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14505"
},
{
"type": "WEB",
"url": "https://github.com/indutny/elliptic/issues/321"
},
{
"type": "PACKAGE",
"url": "https://github.com/indutny/elliptic"
},
{
"type": "WEB",
"url": "https://www.herodevs.com/vulnerability-directory/cve-2025-14505"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Elliptic Uses a Cryptographic Primitive with a Risky Implementation"
}
GHSA-HCP2-X6J4-29J7
Vulnerability from github – Published: 2026-01-13 15:10 – Updated: 2026-04-24 19:58Summary
A timing side-channel was discovered in the Decompose algorithm which is used during ML-DSA signing to generate hints for the signature.
Details
The analysis was performed using a constant-time analyzer that examines compiled assembly code for instructions with data-dependent timing behavior. The analyzer flags:
- UDIV/SDIV instructions: Hardware division instructions have early termination optimizations where execution time depends on operand values.
The decompose function used a hardware division instruction to compute r1.0 / TwoGamma2::U32. This function is called during signing through high_bits() and low_bits(), which process values derived from secret key components:
(&w - &cs2).low_bits()wherecs2is derived from secret key components2Hint::new()callshigh_bits()on values derived from secret key componentt0
Original Code:
fn decompose<TwoGamma2: Unsigned>(self) -> (Elem, Elem) {
// ...
let mut r1 = r_plus - r0;
r1.0 /= TwoGamma2::U32; // Variable-time division on secret-derived data
(r1, r0)
}
PoC
I do not have an exploit written for this, currently.
Impact
The dividend (r1.0) is derived from secret key material. An attacker with precise timing measurements could extract information about the signing key by observing timing variations in the division operation.
Mitigation
Replacing division with constant-time Barrett reduction mitigates this risk. Since TwoGamma2 is a compile-time constant, we precompute the multiplicative inverse:
diff --git a/ml-dsa/src/algebra.rs b/ml-dsa/src/algebra.rs
index 559b68a..bb126ce 100644
--- a/ml-dsa/src/algebra.rs
+++ b/ml-dsa/src/algebra.rs
@@ -54,8 +54,50 @@ pub(crate) trait Decompose {
fn decompose<TwoGamma2: Unsigned>(self) -> (Elem, Elem);
}
+/// Constant-time division by a compile-time constant divisor.
+///
+/// This trait provides a constant-time alternative to the hardware division
+/// instruction, which has variable timing based on operand values.
+/// Uses Barrett reduction to compute `x / M` where M is a compile-time constant.
+pub(crate) trait ConstantTimeDiv: Unsigned {
+ /// Bit shift for Barrett reduction, chosen to provide sufficient precision
+ const CT_DIV_SHIFT: usize;
+ /// Precomputed multiplier: ceil(2^SHIFT / M)
+ const CT_DIV_MULTIPLIER: u64;
+
+ /// Perform constant-time division of x by Self::U32
+ /// Requires: x < Q (the field modulus, ~2^23)
+ #[inline(always)]
+ fn ct_div(x: u32) -> u32 {
+ // Barrett reduction: q = (x * MULTIPLIER) >> SHIFT
+ // This gives us floor(x / M) for x < 2^SHIFT / MULTIPLIER * M
+ let x64 = u64::from(x);
+ let quotient = (x64 * Self::CT_DIV_MULTIPLIER) >> Self::CT_DIV_SHIFT;
+ quotient as u32
+ }
+}
+
+impl<M> ConstantTimeDiv for M
+where
+ M: Unsigned,
+{
+ // Use a shift that provides enough precision for the ML-DSA field (Q ~ 2^23)
+ // We need SHIFT > log2(Q) + log2(M) to ensure accuracy
+ // With Q < 2^24 and M < 2^20, SHIFT = 48 is sufficient
+ const CT_DIV_SHIFT: usize = 48;
+
+ // Precompute the multiplier at compile time
+ // We add (M-1) before dividing to get ceiling division, ensuring we never underestimate
+ #[allow(clippy::integer_division_remainder_used)]
+ const CT_DIV_MULTIPLIER: u64 = ((1u64 << Self::CT_DIV_SHIFT) + M::U64 - 1) / M::U64;
+}
+
impl Decompose for Elem {
// Algorithm 36 Decompose
+ //
+ // This implementation uses constant-time division to avoid timing side-channels.
+ // The original algorithm used hardware division which has variable timing based
+ // on operand values, potentially leaking secret information during signing.
fn decompose<TwoGamma2: Unsigned>(self) -> (Elem, Elem) {
let r_plus = self.clone();
let r0 = r_plus.mod_plus_minus::<TwoGamma2>();
@@ -63,8 +105,9 @@ impl Decompose for Elem {
if r_plus - r0 == Elem::new(BaseField::Q - 1) {
(Elem::new(0), r0 - Elem::new(1))
} else {
- let mut r1 = r_plus - r0;
- r1.0 /= TwoGamma2::U32;
+ let diff = r_plus - r0;
+ // Use constant-time division instead of hardware division
+ let r1 = Elem::new(TwoGamma2::ct_div(diff.0));
(r1, r0)
}
}
See our blog post on how we avoided side-channels in our Go implementation of ML-DSA for more information.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.0-rc.2"
},
"package": {
"ecosystem": "crates.io",
"name": "ml-dsa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.0-rc.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22705"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T15:10:03Z",
"nvd_published_at": "2026-01-10T07:16:03Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA timing side-channel was discovered in the Decompose algorithm which is used during ML-DSA signing to generate hints for the signature.\n\n### Details\n\nThe analysis was performed using a constant-time analyzer that examines compiled assembly code for instructions with data-dependent timing behavior. The analyzer flags:\n\n- **UDIV/SDIV instructions**: Hardware division instructions have early termination optimizations where execution time depends on operand values.\n\nThe `decompose` function used a hardware division instruction to compute `r1.0 / TwoGamma2::U32`. This function is called during signing through `high_bits()` and `low_bits()`, which process values derived from secret key components:\n\n- `(\u0026w - \u0026cs2).low_bits()` where `cs2` is derived from secret key component `s2`\n- `Hint::new()` calls `high_bits()` on values derived from secret key component `t0`\n\n**Original Code**:\n```rust\nfn decompose\u003cTwoGamma2: Unsigned\u003e(self) -\u003e (Elem, Elem) {\n // ...\n let mut r1 = r_plus - r0;\n r1.0 /= TwoGamma2::U32; // Variable-time division on secret-derived data\n (r1, r0)\n}\n```\n\n### PoC\n\nI do not have an exploit written for this, currently.\n\n### Impact\n\nThe dividend (`r1.0`) is derived from secret key material. An attacker with precise timing measurements could extract information about the signing key by observing timing variations in the division operation.\n\n### Mitigation\n\nReplacing division with constant-time Barrett reduction mitigates this risk. Since `TwoGamma2` is a compile-time constant, we precompute the multiplicative inverse:\n\n```patch\ndiff --git a/ml-dsa/src/algebra.rs b/ml-dsa/src/algebra.rs\nindex 559b68a..bb126ce 100644\n--- a/ml-dsa/src/algebra.rs\n+++ b/ml-dsa/src/algebra.rs\n@@ -54,8 +54,50 @@ pub(crate) trait Decompose {\n fn decompose\u003cTwoGamma2: Unsigned\u003e(self) -\u003e (Elem, Elem);\n }\n \n+/// Constant-time division by a compile-time constant divisor.\n+///\n+/// This trait provides a constant-time alternative to the hardware division\n+/// instruction, which has variable timing based on operand values.\n+/// Uses Barrett reduction to compute `x / M` where M is a compile-time constant.\n+pub(crate) trait ConstantTimeDiv: Unsigned {\n+ /// Bit shift for Barrett reduction, chosen to provide sufficient precision\n+ const CT_DIV_SHIFT: usize;\n+ /// Precomputed multiplier: ceil(2^SHIFT / M)\n+ const CT_DIV_MULTIPLIER: u64;\n+\n+ /// Perform constant-time division of x by Self::U32\n+ /// Requires: x \u003c Q (the field modulus, ~2^23)\n+ #[inline(always)]\n+ fn ct_div(x: u32) -\u003e u32 {\n+ // Barrett reduction: q = (x * MULTIPLIER) \u003e\u003e SHIFT\n+ // This gives us floor(x / M) for x \u003c 2^SHIFT / MULTIPLIER * M\n+ let x64 = u64::from(x);\n+ let quotient = (x64 * Self::CT_DIV_MULTIPLIER) \u003e\u003e Self::CT_DIV_SHIFT;\n+ quotient as u32\n+ }\n+}\n+\n+impl\u003cM\u003e ConstantTimeDiv for M\n+where\n+ M: Unsigned,\n+{\n+ // Use a shift that provides enough precision for the ML-DSA field (Q ~ 2^23)\n+ // We need SHIFT \u003e log2(Q) + log2(M) to ensure accuracy\n+ // With Q \u003c 2^24 and M \u003c 2^20, SHIFT = 48 is sufficient\n+ const CT_DIV_SHIFT: usize = 48;\n+\n+ // Precompute the multiplier at compile time\n+ // We add (M-1) before dividing to get ceiling division, ensuring we never underestimate\n+ #[allow(clippy::integer_division_remainder_used)]\n+ const CT_DIV_MULTIPLIER: u64 = ((1u64 \u003c\u003c Self::CT_DIV_SHIFT) + M::U64 - 1) / M::U64;\n+}\n+\n impl Decompose for Elem {\n // Algorithm 36 Decompose\n+ //\n+ // This implementation uses constant-time division to avoid timing side-channels.\n+ // The original algorithm used hardware division which has variable timing based\n+ // on operand values, potentially leaking secret information during signing.\n fn decompose\u003cTwoGamma2: Unsigned\u003e(self) -\u003e (Elem, Elem) {\n let r_plus = self.clone();\n let r0 = r_plus.mod_plus_minus::\u003cTwoGamma2\u003e();\n@@ -63,8 +105,9 @@ impl Decompose for Elem {\n if r_plus - r0 == Elem::new(BaseField::Q - 1) {\n (Elem::new(0), r0 - Elem::new(1))\n } else {\n- let mut r1 = r_plus - r0;\n- r1.0 /= TwoGamma2::U32;\n+ let diff = r_plus - r0;\n+ // Use constant-time division instead of hardware division\n+ let r1 = Elem::new(TwoGamma2::ct_div(diff.0));\n (r1, r0)\n }\n }\n```\n\nSee our blog post on [how we avoided side-channels in our Go implementation of ML-DSA](https://blog.trailofbits.com/2025/11/14/how-we-avoided-side-channels-in-our-new-post-quantum-go-cryptography-libraries/) for more information.",
"id": "GHSA-hcp2-x6j4-29j7",
"modified": "2026-04-24T19:58:16Z",
"published": "2026-01-13T15:10:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/RustCrypto/signatures/security/advisories/GHSA-hcp2-x6j4-29j7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22705"
},
{
"type": "WEB",
"url": "https://github.com/RustCrypto/signatures/pull/1144"
},
{
"type": "WEB",
"url": "https://github.com/RustCrypto/signatures/commit/035d9eef98486ecd00a8bf418c7817eb14dd6558"
},
{
"type": "PACKAGE",
"url": "https://github.com/RustCrypto/signatures"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0144.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "RustCrypto: Signatures has timing side-channel in ML-DSA decomposition"
}
GHSA-HJ49-H7FQ-PX5H
Vulnerability from github – Published: 2025-01-30 19:28 – Updated: 2025-01-30 21:36Impact
Lookup tables, whose length is not divisible by 26 = floor(num_routed_wires / 3) always include the 0 -> 0 input-output pair. Thus a malicious prover can always prove that f(0) = 0 for any lookup table f (unless its length happens to be divisible by 26).
The cause of problem is that the LookupTableGate-s are padded with zeros.
The fix is done by padding with an existing table pair, similarly to LookupGate.
A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.
Fortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:
- both Monolith's and Tip5/Tip4's s-box tables already map 0 to 0;
- more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.
A malicious prover exploiting this could cheat a circuit which statement is the following:
- output x + f(x) for some private input x, where f(x) := 100 - x is implemented by a lookup table.
A malicious prover would be able to convince an honest verifier that they know an 0 <= x < 64 such that x + (100 - x) = 0.
Patches
Yes, upgrade to v1.0.1
Workarounds
No
References
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "plonky2"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.0"
]
}
],
"aliases": [
"CVE-2025-24802"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-30T19:28:51Z",
"nvd_published_at": "2025-01-30T20:15:51Z",
"severity": "HIGH"
},
"details": "### Impact\nLookup tables, whose length is not divisible by `26 = floor(num_routed_wires / 3)` always include the `0 -\u003e 0` input-output pair. Thus a malicious prover can always prove that `f(0) = 0` for any lookup table f (unless its length happens to be divisible by 26).\n\nThe cause of problem is that the `LookupTableGate`-s are [padded with zeros](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97).\n\nThe fix is done by padding with an existing table pair, similarly to `LookupGate`.\n\nA workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26.\n\nFortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable:\n\n* both Monolith\u0027s and Tip5/Tip4\u0027s s-box tables already map 0 to 0;\n* more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace.\n\nA malicious prover exploiting this could cheat a circuit which statement is the following:\n- output `x + f(x)` for some private input `x`, where `f(x) := 100 - x` is implemented by a lookup table.\n\nA malicious prover would be able to convince an honest verifier that they know an `0 \u003c= x \u003c 64` such that `x + (100 - x) = 0`.\n\n### Patches\nYes, upgrade to v1.0.1\n\n### Workarounds\nNo\n\n### References\n\n",
"id": "GHSA-hj49-h7fq-px5h",
"modified": "2025-01-30T21:36:51Z",
"published": "2025-01-30T19:28:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/0xPolygonZero/plonky2/security/advisories/GHSA-hj49-h7fq-px5h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24802"
},
{
"type": "WEB",
"url": "https://github.com/0xPolygonZero/plonky2/commit/091047f7f10cae082716f3738ad59a583835f7b6"
},
{
"type": "PACKAGE",
"url": "https://github.com/0xPolygonZero/plonky2"
},
{
"type": "WEB",
"url": "https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Soundness issue with Plonky2 look up tables"
}
GHSA-J3C9-H64H-GWP9
Vulnerability from github – Published: 2024-02-22 12:30 – Updated: 2025-05-06 18:30B&R Automation Studio Upgrade Service and B&R Technology Guarding use insufficient cryptography for communication to the upgrade and the licensing servers. A network-based attacker could exploit the vulnerability to execute arbitrary code on the products or sniff sensitive data.
Missing Encryption of Sensitive Data, Cleartext Transmission of Sensitive Information, Improper Control of Generation of Code ('Code Injection'), Inadequate Encryption Strength vulnerability in B&R Industrial Automation B&R Automation Studio (Upgrade Service modules), B&R Industrial Automation Technology Guarding.This issue affects B&R Automation Studio: <4.6; Technology Guarding: <1.4.0.
{
"affected": [],
"aliases": [
"CVE-2024-0220"
],
"database_specific": {
"cwe_ids": [
"CWE-1240",
"CWE-311",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-22T11:15:08Z",
"severity": "HIGH"
},
"details": "B\u0026R Automation Studio Upgrade Service and B\u0026R Technology Guarding use insufficient cryptography for communication to the upgrade and the licensing servers. A network-based attacker could exploit the vulnerability to execute arbitrary code on the products or sniff sensitive data.\n\n\n\nMissing Encryption of Sensitive Data, Cleartext Transmission of Sensitive Information, Improper Control of Generation of Code (\u0027Code Injection\u0027), Inadequate Encryption Strength vulnerability in B\u0026R Industrial Automation B\u0026R Automation Studio (Upgrade Service modules), B\u0026R Industrial Automation Technology Guarding.This issue affects B\u0026R Automation Studio: \u003c4.6; Technology Guarding: \u003c1.4.0.",
"id": "GHSA-j3c9-h64h-gwp9",
"modified": "2025-05-06T18:30:30Z",
"published": "2024-02-22T12:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0220"
},
{
"type": "WEB",
"url": "https://www.br-automation.com/fileadmin/SA23P019_Automation_Studio_Upgrade_Service_uses_insufficient_encryption.pdf-1b3b181c.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MHHG-8H3J-Q9XM
Vulnerability from github – Published: 2025-11-05 17:48 – Updated: 2025-11-05 17:48Dell CloudLink, versions prior to 8.2, contain use of a Cryptographic Primitive with a Risky Implementation vulnerability. A high privileged attacker could potentially exploit this vulnerability leading to Denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-46424"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-05T17:15:42Z",
"severity": "MODERATE"
},
"details": "Dell CloudLink, versions prior to 8.2, contain use of a Cryptographic Primitive with a Risky Implementation vulnerability. A high privileged attacker could potentially exploit this vulnerability leading to Denial of service.",
"id": "GHSA-mhhg-8h3j-q9xm",
"modified": "2025-11-05T17:48:29Z",
"published": "2025-11-05T17:48:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46424"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000384363/dsa-2025-374-security-update-for-dell-cloudlink-multiple-security-vulnerabilities"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-QFRV-FMC5-HMMH
Vulnerability from github – Published: 2024-02-23 18:30 – Updated: 2024-02-23 18:30Ember ZNet between v7.2.0 and v7.4.0 used software AES-CCM instead of integrated hardware cryptographic accelerators, potentially increasing risk of electromagnetic and differential power analysis sidechannel attacks.
{
"affected": [],
"aliases": [
"CVE-2023-51392"
],
"database_specific": {
"cwe_ids": [
"CWE-1240",
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-23T17:15:07Z",
"severity": "MODERATE"
},
"details": "Ember ZNet between v7.2.0 and v7.4.0 used software AES-CCM instead of integrated hardware cryptographic accelerators, potentially increasing risk of electromagnetic and differential power analysis sidechannel attacks.",
"id": "GHSA-qfrv-fmc5-hmmh",
"modified": "2024-02-23T18:30:59Z",
"published": "2024-02-23T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51392"
},
{
"type": "WEB",
"url": "https://community.silabs.com/068Vm000001BKm6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R8GC-QC2C-C7VH
Vulnerability from github – Published: 2025-03-14 19:55 – Updated: 2025-03-19 15:26Description:
The secure_redundant_execution function in feldman_vss.py attempts to mitigate fault injection attacks by executing a function multiple times and comparing results. However, several critical weaknesses exist:
- Python's execution environment cannot guarantee true isolation between redundant executions
- The constant-time comparison implementation in Python is subject to timing variations
- The randomized execution order and timing provide insufficient protection against sophisticated fault attacks
- The error handling may leak timing information about partial execution results
These limitations make the protection ineffective against targeted fault injection attacks, especially from attackers with physical access to the hardware.
Impact:
A successful fault injection attack could allow an attacker to:
- Bypass the redundancy check mechanisms
- Extract secret polynomial coefficients during share generation or verification
- Force the acceptance of invalid shares during verification
- Manipulate the commitment verification process to accept fraudulent commitments
This undermines the core security guarantees of the Verifiable Secret Sharing scheme.
References:
- File:
feldman_vss.py - Function:
secure_redundant_execution - Fault Attacks - Wikipedia article on fault attacks.
- Bar-El, H., et al. "The Sorcerer's Apprentice Guide to Fault Attacks" - https://eprint.iacr.org/2004/100.pdf
- CWE-1279: https://cwe.mitre.org/data/definitions/1279.html
- NIST SP 800-90B section on implementation validation
Remediation:
Long-term remediation requires reimplementing the security-critical functions in a lower-level language like Rust.
Short-term mitigations:
- Deploy the software in environments with physical security controls
- Increase the redundancy count (from 5 to a higher number) by modifying the source code
- Add external verification of cryptographic operations when possible
- Consider using hardware security modules (HSMs) for key operations
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "PostQuantum-Feldman-VSS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.0b2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29779"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-14T19:55:17Z",
"nvd_published_at": "2025-03-14T18:15:32Z",
"severity": "MODERATE"
},
"details": "**Description:**\n\nThe `secure_redundant_execution` function in feldman_vss.py attempts to mitigate fault injection attacks by executing a function multiple times and comparing results. However, several critical weaknesses exist:\n\n1. Python\u0027s execution environment cannot guarantee true isolation between redundant executions\n2. The constant-time comparison implementation in Python is subject to timing variations\n3. The randomized execution order and timing provide insufficient protection against sophisticated fault attacks\n4. The error handling may leak timing information about partial execution results\n\nThese limitations make the protection ineffective against targeted fault injection attacks, especially from attackers with physical access to the hardware.\n\n**Impact:**\n\nA successful fault injection attack could allow an attacker to:\n\n1. Bypass the redundancy check mechanisms\n2. Extract secret polynomial coefficients during share generation or verification\n3. Force the acceptance of invalid shares during verification\n4. Manipulate the commitment verification process to accept fraudulent commitments\n\nThis undermines the core security guarantees of the Verifiable Secret Sharing scheme.\n\n**References:**\n\n* File: `feldman_vss.py`\n* Function: `secure_redundant_execution`\n* [Fault Attacks](https://en.wikipedia.org/wiki/Fault_attack) - Wikipedia article on fault attacks.\n* Bar-El, H., et al. \"The Sorcerer\u0027s Apprentice Guide to Fault Attacks\" - https://eprint.iacr.org/2004/100.pdf\n* CWE-1279: https://cwe.mitre.org/data/definitions/1279.html\n* NIST SP 800-90B section on implementation validation\n\n\n**Remediation:**\n\nLong-term remediation requires reimplementing the security-critical functions in a lower-level language like Rust.\n\nShort-term mitigations:\n\n1. Deploy the software in environments with physical security controls\n2. Increase the redundancy count (from 5 to a higher number) by modifying the source code\n3. Add external verification of cryptographic operations when possible\n4. Consider using hardware security modules (HSMs) for key operations",
"id": "GHSA-r8gc-qc2c-c7vh",
"modified": "2025-03-19T15:26:34Z",
"published": "2025-03-14T19:55:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS/security/advisories/GHSA-r8gc-qc2c-c7vh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29779"
},
{
"type": "WEB",
"url": "https://en.wikipedia.org/wiki/Fault_attack"
},
{
"type": "WEB",
"url": "https://eprint.iacr.org/2004/100.pdf"
},
{
"type": "PACKAGE",
"url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:P/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Post-Quantum Secure Feldman\u0027s Verifiable Secret Sharing has Inadequate Fault Injection Countermeasures in `secure_redundant_execution`"
}
GHSA-RV22-CCHR-W8FP
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30This vulnerability stems from a business logic flaw.Attackers can exploit legitimate application functions in unintended and abnormal ways, deviating from the designer's expectations, to carry out malicious attacks.
{
"affected": [],
"aliases": [
"CVE-2026-44410"
],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-26T10:16:18Z",
"severity": "LOW"
},
"details": "This vulnerability stems from a business logic flaw.Attackers can exploit legitimate application functions in unintended and abnormal ways, deviating from the designer\u0027s expectations, to carry out malicious attacks.",
"id": "GHSA-rv22-cchr-w8fp",
"modified": "2026-05-26T13:30:55Z",
"published": "2026-05-26T13:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44410"
},
{
"type": "WEB",
"url": "https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/3711746568357343383"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-55
Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
Mitigation
Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
Mitigation MIT-54
Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.
Mitigation
Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.
Mitigation MIT-52
Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation ("cryptographic agility"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.
Mitigation
Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267].
Mitigation
Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
Mitigation
Do not use a checksum as a substitute for a cryptographically generated hash.
Mitigation
Strategy: Libraries or Frameworks
Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation.
Mitigation
When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.
Mitigation
Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.
CAPEC-97: Cryptanalysis
Cryptanalysis is a process of finding weaknesses in cryptographic algorithms and using these weaknesses to decipher the ciphertext without knowing the secret key (instance deduction). Sometimes the weakness is not in the cryptographic algorithm itself, but rather in how it is applied that makes cryptanalysis successful. An attacker may have other goals as well, such as: Total Break (finding the secret key), Global Deduction (finding a functionally equivalent algorithm for encryption and decryption that does not require knowledge of the secret key), Information Deduction (gaining some information about plaintexts or ciphertexts that was not previously known) and Distinguishing Algorithm (the attacker has the ability to distinguish the output of the encryption (ciphertext) from a random permutation of bits).