Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact The validity store treats a transaction with stored blocknumber = X as "in window" only when X lastbn - transactionvaliditywindowblocks (strict inequality). However the protocol's Transaction::isvalidat accepts a transaction for inclusion in any block in [validitystartheight - blocksperbatch, validitystartheight + window - 1]. By choosing validitystartheight = X + blocksperbatch (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 < validitystartheight + window, i.e., a contiguous window of blocksperbatch - 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
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A remote peer can crash any full node by sending a RequestBatchSet message containing the genesis block's hash. The handler calls getepochchunks which iterates backwards through macro blocks using Policy::macroblockbefore. When it reaches the genesis block number, macroblockbefore panics with "No macro blocks before genesis block". Patches The patch for this vulnerability is formally released as part of v1.5.0. Workarounds No Workaround, although requesting the genesis batch set is not used during normal operation. Resources See PR.
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.