Description

Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Through 1.5.0, the validity store uses a strict lower-bound comparison that expires a stored transaction too early relative to Transaction::is_valid_at, allowing a remote attacker to replay the same signed transaction during a blocks_per_batch minus one block window and cause the sender and recipient balances to be updated twice. This issue is fixed in version 1.5.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T20:17:23.163Z",
  "pubdate": "2026-08-26T20:17:23.163Z",
  "executiveSummary": "The Nimiq Rust implementation of the Albatross consensus algorithm is affected by a transaction replay vulnerability stemming from an improper validation logic error in the validity store. The vulnerability occurs because of an inconsistent strict lower-bound comparison when determining transaction expiration, creating a synchronization mismatch between the validity store and the Transaction::is_valid_at function.\nThis flaw allows a remote, unauthenticated attacker to successfully replay a previously processed, signed transaction within a specific window of blocks—specifically blocks_per_batch minus one. Successful exploitation results in the unauthorized double-processing of a single transaction, leading to unintended modifications of sender and recipient account balances.\nThe vulnerability affects Nimiq versions up to and including 1.5.0. It poses a significant risk to the integrity of the ledger and the consistency of account states within the network. Because the exploit relies on exploiting the consensus mechanism's transaction validation window, it requires no elevated privileges, only the ability to propagate a transaction to the network during the vulnerable temporal window.",
  "technicalDetails": "The core of the vulnerability resides in the validity store component of the Nimiq implementation, which is responsible for tracking transaction history to prevent replay attacks and ensure consensus consistency. The root cause is a logic error where the validity store employs a strict lower-bound comparison to expire stored transactions, which fails to align with the logic defined in Transaction::is_valid_at.\nUnder the Albatross consensus rules, transaction validity is strictly time-bound to prevent replay. However, in versions 1.5.0 and earlier, the validity store prunes transactions prematurely. This creates a state where the local node deems a transaction 'expired' in its validity store tracking, while the broader protocol logic defined by Transaction::is_valid_at still considers the transaction to be valid for processing.\nThe attack flow proceeds as follows: 1. An attacker observes a valid, signed transaction submitted to the network. 2. Due to the premature expiration in the validity store, the node removes the record of the transaction's existence before the protocol-level block window has actually closed. 3. The attacker re-broadcasts the identical signed transaction within the window of blocks_per_batch minus one. 4. Because the node has already cleared the transaction from its validity store (the 'memory' of the transaction), it fails to identify the transaction as a duplicate. 5. The node treats the replayed transaction as a new, legitimate request and re-executes the transaction logic.\nThis behavior results in a double-spend scenario where the sender's balance is debited twice and the recipient's balance is credited twice for a single original intent. This bypasses the intended state machine protection of the Proof-of-Stake protocol. The attack does not require authentication, as the transaction is already correctly signed; the vulnerability lies in the node's failure to maintain sufficient state to identify the replay attempt. The exposure is network-wide, as any node running the vulnerable version within the consensus validator set or as a full node can be induced to process the replayed transaction if it is broadcast at the opportune time during the blocks_per_batch cycle."
}