Search vulnerabilities

Results 27

Export CSV
CVE-2026-34064

nimiq-account: Vesting insufficient funds error can panic

nimiq-account contains account primitives to be used in Nimiq's Rust implementation. Prior to version 1.3.0, `VestingContract::can_change_balance` returns `AccountError::InsufficientFunds` when `new_balance < min_cap`, but it constructs the error using `balance: self.balance - min_cap`. `Coin::sub` panics on underflow, so if an attacker can reach a state where `min_cap > balance`, the node crashes while trying to return an error. The `min_cap > balance` precondition is attacker-reachable because the vesting contract creation data (32-byte format) allows encoding `total_amount` without validating `total_amount <= transaction.value` (the real contract balance). After creating such a vesting contract, the attacker can broadcast an outgoing transaction to trigger the panic during mempool admission and block processing. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2026-34065

nimiq-primitives: Node crash due to missing interlink validation in election macro block proposals

nimiq-primitives contains primitives (e.g., block, account, transaction) to be used in Nimiq's Rust implementation. Prior to version 1.3.0, an untrusted p2p peer can cause a node to panic by announcing an election macro block whose `validators` set contains an invalid compressed BLS voting key. Hashing an election macro header hashes `validators` and reaches `Validators::voting_keys()`, which calls `validator.voting_key.uncompress().unwrap()` and panics on invalid bytes. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
CVE-2026-34066

nimiq-blockchain: Peer-triggerable panic during history sync

nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. Prior to version 1.3.0, `HistoryStore::put_historic_txns` uses an `assert!` to enforce invariants about `HistoricTransaction.block_number` (must be within the macro block being pushed and within the same epoch). During history sync, a peer can influence the `history: &[HistoricTransaction]` input passed into `Blockchain::push_history_sync`, and a malformed history list can violate these invariants and trigger a panic. `extend_history_sync` calls `this.history_store.add_to_history(..)` before comparing the computed history root against the macro block header (`block.history_root()`), so the panic can happen before later rejection checks run. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2026-34067

nimiq-transaction vulnerable to panic via `HistoryTreeProof` length mismatch

nimiq-transaction provides the transaction primitive to be used in Nimiq's Rust implementation. Prior to version 1.3.0, `HistoryTreeProof::verify` panics on a malformed proof where `history.len() != positions.len()` due to `assert_eq!(history.len(), positions.len())`. The proof object is derived from untrusted p2p responses (`ResponseTransactionsProof.proof`) and is therefore attacker-controlled at the network boundary until validated. A malicious peer could trigger a crash by returning a crafted inclusion proof with a length mismatch. The patch for this vulnerability is included as part of v1.3.0. No known workarounds are available.

CVSS 3.1 · 3.1 Low EPSS < 1% KEV · Not listed
Vendors
CVE-2026-32605

Nimiq: Remote crash via off-by-one signer bounds check in proposal buffer

nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.3.0, an untrusted peer could crash a validator by publishing a signed tendermint proposal message where signer == validators.num_validators(). ProposalSender::send uses > instead of >= for the signer bounds check, so the equality case passes and reaches validators.get_validator_by_slot_band(signer), which panics with an out-of-bounds index before any signature verification runs. This issue has been fixed in version 1.3.0.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
CVE-2026-40093

nimiq-blockchain is missing a wall-clock upper bound on block timestamps

nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. In 1.3.0 and earlier, block timestamp validation enforces that timestamp >= parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via Policy::supply_at() and batch_delay() in blockchain/src/reward.rs, inflating the monetary supply beyond the intended emission schedule.

CVSS 3.1 · 8.1 High EPSS < 1% KEV · Not listed
Vendors
CVE-2026-34069

nimiq-consensus panics via RequestMacroChain micro-block locator

nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. In versions 1.2.2 and below, an unauthenticated p2p peer can cause the RequestMacroChain message handler task to panic. Sending a RequestMacroChain message where the first locator hash on the victim’s main chain is a micro block hash (not a macro block hash) causes said panic. The RequestMacroChain::handle handler selects the locator based only on "is on main chain", then calls get_macro_blocks() and panics via .unwrap() when the selected hash is not a macro block (BlockchainError::BlockIsNotMacro). This issue has been fixed in version 1.3.0.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed
Vendors