CVE-2026-46369: 
Rust vulnerability analysis and mitigation

CVE-2026-46369 is a validity store off-by-one error in the Nimiq blockchain (nimiq-blockchain) Rust crate that enables transaction replay attacks. The flaw affects all versions up to and including nimiq-blockchain v1.5.0 (part of the core-rs-albatross repository) and was patched in v1.5.1. It was published by researcher viquezclaudio on August 11, 2026, and added to the GitHub Advisory Database on August 12, 2026. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Nimiq Advisory).

The root cause is a mismatch between the validity store's replay-protection window and the protocol's actual transaction validity range, classified as CWE-193 (Off-by-one Error) and CWE-294 (Authentication Bypass by Capture-replay). The ValidityStore::has_transaction function used a strict inequality (X > last_bn - transaction_validity_window_blocks) to determine if a stored transaction is still "in window," but the protocol's Transaction::is_valid_at accepts a transaction for inclusion in any block within [validity_start_height - blocks_per_batch, validity_start_height + window - 1]. By crafting a transaction with validity_start_height = X + blocks_per_batch (the maximum value still allowing first inclusion at block X), an attacker opens a gap of blocks_per_batch - 1 blocks (59 blocks on MainNet, approximately 10 minutes) during which the replay-protection check incorrectly considers the transaction expired. The fix, merged in PR #3772, extends the lookback window in ValidityStore::has_transaction to transaction_validity_window_blocks + blocks_per_batch to fully cover the protocol's validity range (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated network attacker to replay a previously executed, legitimately signed transaction during a ~10-minute window on MainNet. The direct financial consequence is double-execution: the sender's account is debited twice and the recipient's account is credited twice, resulting in unauthorized fund duplication and ledger integrity violations. There is no confidentiality or availability impact, but the integrity of the blockchain's transaction ledger is directly compromised (GitHub Advisory, Nimiq Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported. The CVE status is listed as "Reserved" and no EPSS score or CISA KEV catalog entry is available. The attack requires no privileges or user interaction and is exploitable remotely over the network, but it does require the attacker to possess (or observe) a valid signed transaction and to time the replay within the specific vulnerable block window (GitHub Advisory).

1. Obtain a signed transaction: Acquire a valid, signed Nimiq transaction — either by being the sender, intercepting a broadcast, or observing one on-chain — that was first included at block X.
2. Calculate the replay window: Determine validity_start_height = X + blocks_per_batch. Identify the vulnerable replay window: any block B where X + window < B < validity_start_height + window (a span of up to 59 consecutive blocks on MainNet, ~10 minutes).
3. Craft the replay transaction: Reuse the exact same signed transaction bytes. The transaction's validity_start_height must equal X + blocks_per_batch to maximize the replay window while remaining protocol-valid for first inclusion at block X.
4. Submit the replay: Broadcast the identical signed transaction to the Nimiq network during the vulnerable block window. The validity store's off-by-one check will fail to flag it as a duplicate.
5. Double execution achieved: The network accepts and executes the transaction a second time, debiting the sender twice and crediting the recipient twice (GitHub Advisory, Nimiq Advisory).

• On-chain: Duplicate transaction hashes appearing in blocks separated by up to 59 blocks; sender account balance decremented twice for a single intended transfer; recipient account balance incremented twice unexpectedly.
• Node Logs: Validity store lookups returning false (not in window) for a transaction hash that was recently included in a block within the last transaction_validity_window_blocks blocks, followed by successful re-inclusion of the same transaction.
• Network: Identical raw transaction bytes broadcast to the network more than once within a ~10-minute window after the transaction's first confirmed inclusion.

Upgrade the nimiq-blockchain Rust crate to version v1.5.1, which extends ValidityStore::has_transaction to use a lookback of transaction_validity_window_blocks + blocks_per_batch, closing the off-by-one gap. The fix was merged in PR #3772 and released on May 21, 2026. There are no known workarounds; upgrading is the only remediation (GitHub Advisory, Patch PR).