GHSA-3763-QP59-59VF

Vulnerability from github – Published: 2026-08-12 15:16 – Updated: 2026-08-12 15:16
VLAI
Summary
nimiq-blockchain: Validity store off by one error
Details

Impact

The validity store treats a transaction with stored block_number = X as "in window" only when X > last_bn - transaction_validity_window_blocks (strict inequality). However the protocol's Transaction::is_valid_at accepts a transaction for inclusion in any block in [validity_start_height - blocks_per_batch, validity_start_height + window - 1]. By choosing validity_start_height = X + blocks_per_batch (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that X + window < B < validity_start_height + window, i.e., a contiguous window of blocks_per_batch - 1 blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.

Patches

https://github.com/nimiq/core-rs-albatross/pull/3772

Workarounds

No known workarounds

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "nimiq-blockchain"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46369"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193",
      "CWE-294"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T15:16:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nThe validity store treats a transaction with stored `block_number = X` as \"in window\" only when `X \u003e last_bn - transaction_validity_window_blocks` (strict inequality). However the protocol\u0027s `Transaction::is_valid_at` accepts a transaction for inclusion in any block in `[validity_start_height - blocks_per_batch, validity_start_height + window - 1]`. By choosing `validity_start_height = X + blocks_per_batch` (the largest value still compatible with first inclusion at block X), an attacker can replay the same signed transaction in any block B such that `X + window \u003c B \u003c validity_start_height + window`, i.e., a contiguous window of `blocks_per_batch - 1` blocks (59 on MainNet, ~10 minutes) during which the replay-protection check fails to flag it. The same transaction is then executed twice: the sender is debited twice, the recipient credited twice.\n\n### Patches\nhttps://github.com/nimiq/core-rs-albatross/pull/3772\n\n### Workarounds\nNo known workarounds",
  "id": "GHSA-3763-qp59-59vf",
  "modified": "2026-08-12T15:16:53Z",
  "published": "2026-08-12T15:16:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-3763-qp59-59vf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/pull/3772"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/commit/a530b2434ebca6e3716f07c73079786fcc6f2e41"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nimiq/core-rs-albatross"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nimiq-blockchain: Validity store off by one error"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…