GHSA-5X2R-HC65-25F9

Vulnerability from github – Published: 2026-01-28 16:44 – Updated: 2026-01-28 16:44
VLAI
Summary
ML-DSA Signature Verification Accepts Signatures with Repeated Hint Indices
Details

Affected Crate: ml-dsa
Affected Versions: v0.1.0-rc.2 (and commits since b01c3b7)
Severity: Medium
Reporter: Oren Yomtov (Fireblocks)

Summary

The ML-DSA signature verification implementation in the RustCrypto ml-dsa crate incorrectly accepts signatures with repeated (duplicate) hint indices. According to the ML-DSA specification (FIPS 204 / RFC 9881), hint indices within each polynomial must be strictly increasing. The current implementation uses a non-strict monotonic check (<= instead of <), allowing duplicate indices.

Note: This is a regression bug. The original implementation was correct, but commit b01c3b7 ("Make ML-DSA signature decoding follow the spec (#895)", fixing issue #894) inadvertently changed the strict < comparison to <=, introducing the vulnerability.

Vulnerability Details

Root Cause

The vulnerability is located in the monotonic helper function in ml-dsa/src/hint.rs:

fn monotonic(a: &[usize]) -> bool {
    a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] <= *x)
}

The comparison operator <= allows equal consecutive values, meaning duplicate hint indices are not rejected. The correct implementation should use strict less-than (<):

fn monotonic(a: &[usize]) -> bool {
    a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] < *x)
}

Regression Analysis

  • Original correct code (commit 1d3a1d1 - "Add support for ML-DSA (#877)"): Used < (strict)
  • Bug introduced (commit b01c3b7 - "Make ML-DSA signature decoding follow the spec (#895)"): Changed to <=

The commit message suggests it was intended to fix issue #894 and make decoding follow the spec, but the change to the monotonic function was in the wrong direction. The other changes in that commit (to use_hint function) may have been correct, but this specific change introduced signature malleability.

Technical Impact

This vulnerability allows signature malleability - the same logical signature can have multiple valid byte-level encodings. An attacker can take a valid signature and create additional "valid" signatures by duplicating hint indices.

Per the ML-DSA specification (FIPS 204, Section 6.2 and Algorithm 26 HintBitUnpack), hint indices must be strictly increasing to ensure a unique, canonical encoding. Accepting non-canonical signatures can lead to:

  1. Signature Malleability: Multiple distinct byte sequences verify as valid for the same message/key pair
  2. Protocol-Level Vulnerabilities: Systems that rely on signature uniqueness (e.g., for transaction deduplication, replay protection, or signature-based identifiers) may be vulnerable
  3. Interoperability Issues: Non-compliant signatures may be rejected by other conforming implementations

Affected Security Levels

All ML-DSA parameter sets are affected: - ML-DSA-44 (NIST Security Level 2) - ML-DSA-65 (NIST Security Level 3) - ML-DSA-87 (NIST Security Level 5)

Proof of Concept

See the file poc_mldsa_repeated_hint.rs for a standalone proof of concept that demonstrates the vulnerability.

The PoC uses test vectors from the Wycheproof test suite that specifically test for this invalid encoding:

  • Test Vector Source: Wycheproof ML-DSA Test Vectors
  • Test Case ID 18: "signature with a repeated hint"
  • Expected Result: invalid
  • Actual Result: valid (BUG)

Remediation

Update the monotonic function in ml-dsa/src/hint.rs to use strict less-than comparison:

fn monotonic(a: &[usize]) -> bool {
    a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] < *x)
}

Design Intent: ML-DSA is NOT Intended to Allow Malleability

While some cryptographic libraries intentionally permit signature malleability for compatibility or performance reasons, ML-DSA is explicitly designed to prevent it:

  1. FIPS 204 Specification: ML-DSA is designed to be strongly unforgeable under chosen message attacks (SUF-CMA). This security property explicitly prevents signature malleability.

  2. NIST PQC Forum Discussion: In February 2024, there was a discussion on the NIST PQC forum about potential malleability in ML-DSA's hint unpacking. The consensus was that ML-DSA is intended to be SUF-CMA, meaning any malleability issues should be considered bugs and fixed.

  3. No Documentation of Intentional Malleability: There is no documentation in the RustCrypto ml-dsa crate, FIPS 204, or RFC 9881 suggesting that signature malleability is an acceptable or intentional property.

  4. Regression Bug: The fact that the original implementation had strict ordering (<) and this was changed to non-strict (<=) in a "fix" commit suggests this was an unintentional regression, not a design decision.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "ml-dsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.4"
            },
            {
              "fixed": "0.1.0-rc.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-28T16:44:47Z",
    "nvd_published_at": "2026-01-28T01:16:15Z",
    "severity": "MODERATE"
  },
  "details": "**Affected Crate:** `ml-dsa`  \n**Affected Versions:** v0.1.0-rc.2 (and commits since `b01c3b7`)  \n**Severity:** Medium  \n**Reporter:** Oren Yomtov (Fireblocks)\n\n## Summary\n\nThe ML-DSA signature verification implementation in the RustCrypto `ml-dsa` crate incorrectly accepts signatures with repeated (duplicate) hint indices. According to the ML-DSA specification (FIPS 204 / RFC 9881), hint indices within each polynomial must be **strictly increasing**. The current implementation uses a non-strict monotonic check (`\u003c=` instead of `\u003c`), allowing duplicate indices.\n\n**Note:** This is a regression bug. The original implementation was correct, but commit `b01c3b7` (\"Make ML-DSA signature decoding follow the spec (#895)\", fixing issue #894) inadvertently changed the strict `\u003c` comparison to `\u003c=`, introducing the vulnerability.\n\n## Vulnerability Details\n\n### Root Cause\n\nThe vulnerability is located in the `monotonic` helper function in `ml-dsa/src/hint.rs`:\n\n```rust\nfn monotonic(a: \u0026[usize]) -\u003e bool {\n    a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] \u003c= *x)\n}\n```\n\nThe comparison operator `\u003c=` allows equal consecutive values, meaning duplicate hint indices are not rejected. The correct implementation should use strict less-than (`\u003c`):\n\n```rust\nfn monotonic(a: \u0026[usize]) -\u003e bool {\n    a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] \u003c *x)\n}\n```\n\n### Regression Analysis\n\n- **Original correct code** (commit `1d3a1d1` - \"Add support for ML-DSA (#877)\"): Used `\u003c` (strict)\n- **Bug introduced** (commit `b01c3b7` - \"Make ML-DSA signature decoding follow the spec (#895)\"): Changed to `\u003c=`\n\nThe commit message suggests it was intended to fix issue #894 and make decoding follow the spec, but the change to the `monotonic` function was in the wrong direction. The other changes in that commit (to `use_hint` function) may have been correct, but this specific change introduced signature malleability.\n\n### Technical Impact\n\nThis vulnerability allows **signature malleability** - the same logical signature can have multiple valid byte-level encodings. An attacker can take a valid signature and create additional \"valid\" signatures by duplicating hint indices.\n\nPer the ML-DSA specification (FIPS 204, Section 6.2 and Algorithm 26 `HintBitUnpack`), hint indices must be strictly increasing to ensure a unique, canonical encoding. Accepting non-canonical signatures can lead to:\n\n1. **Signature Malleability:** Multiple distinct byte sequences verify as valid for the same message/key pair\n2. **Protocol-Level Vulnerabilities:** Systems that rely on signature uniqueness (e.g., for transaction deduplication, replay protection, or signature-based identifiers) may be vulnerable\n3. **Interoperability Issues:** Non-compliant signatures may be rejected by other conforming implementations\n\n### Affected Security Levels\n\nAll ML-DSA parameter sets are affected:\n- ML-DSA-44 (NIST Security Level 2)\n- ML-DSA-65 (NIST Security Level 3)\n- ML-DSA-87 (NIST Security Level 5)\n\n## Proof of Concept\n\nSee the file [`poc_mldsa_repeated_hint.rs`](https://gist.github.com/orenyomtov/fb4616eb77d33017f41a71b30aa41a04) for a standalone proof of concept that demonstrates the vulnerability.\n\nThe PoC uses test vectors from the Wycheproof test suite that specifically test for this invalid encoding:\n\n- **Test Vector Source:** [Wycheproof ML-DSA Test Vectors](https://github.com/C2SP/wycheproof/blob/master/testvectors_v1/mldsa_44_verify_test.json)\n- Test Case ID 18: \"signature with a repeated hint\"\n- Expected Result: `invalid`\n- Actual Result: `valid` (BUG)\n\n## Remediation\n\nUpdate the `monotonic` function in `ml-dsa/src/hint.rs` to use strict less-than comparison:\n\n```rust\nfn monotonic(a: \u0026[usize]) -\u003e bool {\n    a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] \u003c *x)\n}\n```\n\n## Design Intent: ML-DSA is NOT Intended to Allow Malleability\n\nWhile some cryptographic libraries intentionally permit signature malleability for compatibility or performance reasons, **ML-DSA is explicitly designed to prevent it**:\n\n1. **FIPS 204 Specification:** ML-DSA is designed to be strongly unforgeable under chosen message attacks (SUF-CMA). This security property explicitly prevents signature malleability.\n\n2. **NIST PQC Forum Discussion:** In February 2024, there was a discussion on the NIST PQC forum about potential malleability in ML-DSA\u0027s hint unpacking. The consensus was that ML-DSA is intended to be SUF-CMA, meaning any malleability issues should be considered bugs and fixed.\n\n3. **No Documentation of Intentional Malleability:** There is no documentation in the RustCrypto `ml-dsa` crate, FIPS 204, or RFC 9881 suggesting that signature malleability is an acceptable or intentional property.\n\n4. **Regression Bug:** The fact that the original implementation had strict ordering (`\u003c`) and this was changed to non-strict (`\u003c=`) in a \"fix\" commit suggests this was an unintentional regression, not a design decision.",
  "id": "GHSA-5x2r-hc65-25f9",
  "modified": "2026-01-28T16:44:47Z",
  "published": "2026-01-28T16:44:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/security/advisories/GHSA-5x2r-hc65-25f9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24850"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/issues/894"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/pull/895"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/commit/400961412be2e2ab787942cf30e0a9b66b37a54a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RustCrypto/signatures/commit/b01c3b73dd08d0094e089aa234f78b6089ec1f38"
    },
    {
      "type": "WEB",
      "url": "https://csrc.nist.gov/pubs/fips/204/final"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc9881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/C2SP/wycheproof"
    },
    {
      "type": "WEB",
      "url": "https://github.com/C2SP/wycheproof/blob/master/testvectors_v1/mldsa_44_verify_test.json"
    },
    {
      "type": "WEB",
      "url": "https://github.com/C2SP/wycheproof/blob/master/testvectors_v1/mldsa_65_verify_test.json"
    },
    {
      "type": "WEB",
      "url": "https://github.com/C2SP/wycheproof/blob/master/testvectors_v1/mldsa_87_verify_test.json"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/RustCrypto/signatures"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ML-DSA Signature Verification Accepts Signatures with Repeated Hint Indices"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.