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.
46 vulnerabilities reference this CWE, most recent first.
GHSA-6WJW-QF87-FV5V
Vulnerability from github – Published: 2024-05-15 22:01 – Updated: 2024-05-15 22:01A potential exploit of the Laravel Encrypter component that may cause the Encrypter to fail on decryption and unexpectedly return false.
To exploit this, the attacker must be able to modify the encrypted payload before it is decrypted. Depending on the code within your application, this could lead to unexpected behavior when combined with weak type comparisons, for example:
<?php
$decyptedValue = decrypt($secret);
if ($decryptedValue == '') {
// Code is run even though decrypted value is false...
}
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "illuminate/encryption"
},
"ranges": [
{
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.5.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "illuminate/encryption"
},
"ranges": [
{
"events": [
{
"introduced": "5.6.0"
},
{
"fixed": "5.6.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-15T22:01:01Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "A potential exploit of the Laravel Encrypter component that may cause the Encrypter to fail on decryption and unexpectedly return false.\n\nTo exploit this, the attacker must be able to modify the encrypted payload before it is decrypted. Depending on the code within your application, this could lead to unexpected behavior when combined with weak type comparisons, for example:\n\n```php\n\u003c?php\n\n$decyptedValue = decrypt($secret);\n\nif ($decryptedValue == \u0027\u0027) {\n // Code is run even though decrypted value is false...\n}\n```",
"id": "GHSA-6wjw-qf87-fv5v",
"modified": "2024-05-15T22:01:01Z",
"published": "2024-05-15T22:01:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/illuminate/encryption/commit/51667a52bd7d135c6aa40a897656ffe9d3cd072d"
},
{
"type": "WEB",
"url": "https://github.com/illuminate/encryption/commit/c80b1da6a0412bd74bd56dc80f6126f561631b05"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/illuminate/encryption/2018-03-30-1.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/illuminate/encryption"
},
{
"type": "WEB",
"url": "https://medium.com/@taylorotwell/laravel-security-release-5-6-15-and-5-5-40-56f1257933a0"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Laravel Encrypter Failure to decryption vulnerability"
}
GHSA-753P-WRJ5-G8FJ
Vulnerability from github – Published: 2024-12-11 21:47 – Updated: 2024-12-11 21:48Impact
A correctness error has been identified in the reference implementation of the HQC key encapsulation mechanism. Due to an indexing error, part of the secret key is incorrectly treated as non-secret data. This results in an incorrect shared secret value being returned when the decapsulation function is called with a malformed ciphertext.
No concrete attack exploiting the error has been identified at this point. However, the error involves mishandling of the secret key, and in principle this presents a security vulnerability.
Patches
PQClean does not have a release process, as it is a collection of implementations. If you obtained a HQC implementation from PQClean, please update to a version that includes the fixes proposed in https://github.com/PQClean/PQClean/pull/578.
Please also refer to our security policy.
Workarounds
Manually patching is always possible
Further details
In the 2023/04/30 version of the HQC specification and reference implementation, an extra field (sigma) was added to the secret key structure to enable implicit rejection of malformed ciphertexts. The logic to retrieve the public key from the secret key in the decapsulation function was not updated accordingly. As a result, sigma is treated as part of the public key. Later in the decapsulation call, a incorrectly constructed comparison check allows this error to go through undetected. Due to how these two bugs interfere with each other, the decapsulation function never uses sigma to perform implicit rejection; instead, it accepts malformed ciphertexts and returns shared secrets based on their decryptions.
References
This issue was first reported in OQS https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-gpf4-vrrw-r8v7. The vulnerability was identified by Célian Glénaz and Dahmun Goudarzi (Quarkslab).
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "pqcrypto-hqc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1240",
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-11T21:47:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nA correctness error has been identified in the reference implementation of the HQC key encapsulation mechanism. Due to an indexing error, part of the secret key is incorrectly treated as non-secret data. This results in an incorrect shared secret value being returned when the decapsulation function is called with a malformed ciphertext.\n\nNo concrete attack exploiting the error has been identified at this point. However, the error involves mishandling of the secret key, and in principle this presents a security vulnerability.\n\n### Patches\n\nPQClean does not have a release process, as it is a collection of implementations. If you obtained a HQC implementation from PQClean, please update to a version that includes the fixes proposed in https://github.com/PQClean/PQClean/pull/578. \n\nPlease also [refer to our security policy](https://github.com/PQClean/PQClean/blob/master/SECURITY.md).\n\n### Workarounds\n\nManually patching is always possible\n\n### Further details\n\nIn the 2023/04/30 version of the HQC specification and reference implementation, an extra field (sigma) was added to the secret key structure to enable implicit rejection of malformed ciphertexts. The logic to retrieve the public key from the secret key in the decapsulation function was not updated accordingly. As a result, sigma is treated as part of the public key. Later in the decapsulation call, a incorrectly constructed comparison check allows this error to go through undetected. Due to how these two bugs interfere with each other, the decapsulation function never uses sigma to perform implicit rejection; instead, it accepts malformed ciphertexts and returns shared secrets based on their decryptions.\n\n### References\n\nThis issue was first reported in OQS https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-gpf4-vrrw-r8v7. The vulnerability was identified by C\u00e9lian Gl\u00e9naz and Dahmun Goudarzi (Quarkslab).\n",
"id": "GHSA-753p-wrj5-g8fj",
"modified": "2024-12-11T21:48:32Z",
"published": "2024-12-11T21:47:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/PQClean/PQClean/security/advisories/GHSA-753p-wrj5-g8fj"
},
{
"type": "WEB",
"url": "https://github.com/open-quantum-safe/liboqs/security/advisories/GHSA-gpf4-vrrw-r8v7"
},
{
"type": "WEB",
"url": "https://github.com/PQClean/PQClean/pull/578"
},
{
"type": "WEB",
"url": "https://github.com/rustpq/pqcrypto/commit/0c07fa8badbf44f67d3ff1571df31ca54e5228c0"
},
{
"type": "PACKAGE",
"url": "https://github.com/PQClean/PQClean"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "PQClean has a correctness error in HQC decapsulation"
}
GHSA-7852-W36X-6MF6
Vulnerability from github – Published: 2024-05-15 22:08 – Updated: 2024-05-15 22:08The Laravel Encrypter component is susceptible to a vulnerability that may result in decryption failure, leading to an unexpected return of false. Exploiting this issue requires the attacker to manipulate the encrypted payload before decryption. When combined with weak type comparisons in the application's code, such as the example below:
<?php
$decyptedValue = decrypt($secret);
if ($decryptedValue == '') {
// Code is run even though decrypted value is false...
}
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "laravel/framework"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.5.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "laravel/framework"
},
"ranges": [
{
"events": [
{
"introduced": "5.6.0"
},
{
"fixed": "5.6.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1240"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-15T22:08:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The Laravel Encrypter component is susceptible to a vulnerability that may result in decryption failure, leading to an unexpected return of `false`. Exploiting this issue requires the attacker to manipulate the encrypted payload before decryption. When combined with weak type comparisons in the application\u0027s code, such as the example below:\n\n```\n\u003c?php\n\n$decyptedValue = decrypt($secret);\n\nif ($decryptedValue == \u0027\u0027) {\n // Code is run even though decrypted value is false...\n}\n```",
"id": "GHSA-7852-w36x-6mf6",
"modified": "2024-05-15T22:08:06Z",
"published": "2024-05-15T22:08:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/laravel/framework/commit/28e53f23a76206fb130e9a54eb95aa3f010e79c9"
},
{
"type": "WEB",
"url": "https://github.com/laravel/framework/commit/886d261df0854426b4662b7ed5db6a1c575a4279"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/laravel/framework/2018-03-30-1.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/laravel/framework"
},
{
"type": "WEB",
"url": "https://medium.com/@taylorotwell/laravel-security-release-5-6-15-and-5-5-40-56f1257933a0"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Laravel Encrypter Component Potential Decryption Failure Leading to Unintended Behavior"
}
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"
}
]
}
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).