CVE-2026-46369 in core-rs-albatross
Summary
by MITRE • 08/26/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Nimiq versions prior to 1.5.1 represents a critical logic flaw within the validity store component of its Rust-based implementation, which utilizes the Albatross consensus algorithm for Proof-of-Stake operations. This issue stems from an incorrect boundary condition check when determining whether a stored transaction remains valid for inclusion in subsequent blocks. Specifically, the system employs a strict lower-bound comparison that prematurely expires transactions relative to the intended validity window defined by the Transaction::is_valid_at method. In cryptographic ledger systems like Nimiq, maintaining precise temporal consistency of transaction lifecycles is paramount to ensuring atomicity and preventing double-spending or unauthorized balance modifications. The flaw allows for a deviation from the expected protocol behavior where a signed transaction remains considered valid in the validity store even after it should have been discarded based on block height thresholds.
From an operational perspective, this logic error creates a significant window of opportunity for remote attackers to exploit the discrepancy between the stored validity state and the actual consensus rules. By leveraging the gap created by the strict lower-bound comparison, an attacker can replay the same signed transaction within a specific temporal range defined as blocks_per_batch minus one block. During this narrow window, the network processes the identical transaction multiple times because each instance is deemed valid by the flawed store mechanism before it is properly expired. This results in the sender and recipient balances being updated twice for a single economic event, effectively allowing an attacker to duplicate funds or manipulate account states without authorization. Such behavior undermines the integrity of the blockchain ledger and violates fundamental principles of distributed consensus where every transaction must be processed exactly once under normal network conditions.
This vulnerability aligns with CWE-841, which describes Improper Enforcement of Behavioral Workflow, as the system fails to correctly enforce the sequence and timing constraints required for transaction validity. Furthermore, in the context of the MITRE ATT&CK framework, this exploit technique relates to Tactic TA0005 Defense Evasion or potentially TA0003 Persistence depending on how the replay is orchestrated, but more accurately it falls under techniques involving manipulation of system state such as T1496 Resource Hijacking if used for financial gain through double spending. The core issue lies in the failure to properly validate temporal constraints against consensus rules, allowing an adversary to bypass intended security controls inherent in the protocol design.
To mitigate this vulnerability, users must upgrade immediately to Nimiq version 1.5.1 or later, where the validity store logic has been corrected to align strictly with Transaction::is_valid_at expectations. Network operators should ensure that all nodes are updated simultaneously during a coordinated hard fork if necessary to prevent chain splits caused by inconsistent validation states across peers. Additionally, developers implementing similar consensus mechanisms in other systems should audit their boundary condition checks for expiration times and validity windows, ensuring that strict inequalities do not inadvertently extend the lifespan of transactions beyond their intended scope. Regular penetration testing focused on edge cases involving block height thresholds and transaction replay attacks is recommended to detect such logical flaws before they can be exploited in production environments.