Nimiq Albatross EUVD-2026-66705

The attacker must be able to submit transactions to the Nimiq Albatross peer-to-peer network, which is standard capability for any network participant and requires no authentication (consistent with CVSS PR:N). The attacker must construct their transaction with validity_start_height = first_inclusion_block + blocks_per_batch - a field the attacker controls when crafting their own transactions, requiring no special access to third-party keys or systems. The replay window is constrained to blocks_per_batch - 1 contiguous blocks (59 blocks, approximately 10 minutes on MainNet), after which the protocol itself rejects the transaction as expired. Exploitation is limited to nodes running nimiq-blockchain 1.5.0 or earlier in the Albatross implementation; validators operating patched version 1.5.1 will correctly flag the replayed transaction. No non-default configuration is required - the flaw is present in the standard validity store logic.

CVSS 7.5 High (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) reflects the financial integrity impact directly: no authentication or elevated privileges required, network accessible, high integrity loss from double-spend execution. EPSS data is absent from the provided input and cannot be inferred. No CISA KEV listing exists, and no public proof-of-concept has been identified at time of analysis; these signals collectively lower the probability of immediate widespread exploitation. Real-world risk is bounded by the niche deployment footprint of Nimiq Albatross relative to major blockchain ecosystems. Notably, the 'Information Disclosure' tag applied by the data source conflicts with the actual impact - the vulnerability produces financial integrity loss (double-spend), not confidentiality exposure; this tag appears to be a misclassification. Given the availability of a vendor patch (1.5.1) and the absence of KEV or POC signals, the primary urgency is for active Nimiq MainNet node operators.

An attacker broadcasts a transaction to the Nimiq MainNet with validity_start_height set to first_inclusion_block + blocks_per_batch, ensuring the transaction is first included at block X. Once the validity store's strict-inequality check causes it to drop replay protection after block X + window, the attacker rebroadcasts the identical signed transaction; validators on vulnerable 1.5.0 nodes accept it as novel, include it in a subsequent block, and execute it a second time - crediting the recipient a second time and debiting the sender a second time. No public exploit code exists at time of analysis.