- Top reward
- $50,000
- Top severity paid
- Critical
- Assets in scope
- 1
- Public CVEs
- 15
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $50,000
- for critical bugs.
- Report on HackerOne
- Submit through the program page.
Rewards
What HackerOne lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical |
|
$50,000 from $25,000 |
| High |
|
$10,000 from $5,000 |
| Medium |
|
$2,000 from $1,000 |
| Low |
|
$500 from $100 |
Earlier reward tables (1)
- 12 Nov 2026 to 12 Nov 2026: Critical up to $50,000
Scope
1 asset you may test, 7 excluded.
Source code 1
- https://github.com/nimiq/core-rs-albatross No bounty
Out of scope (7)
- Blockchain testnet
- https://github.com/nimiq/core-js/
- https://github.com/nimiq/core-rs/
- https://github.com/nimiq/ledger-app-nimiq
- https://keyguard.nimiq.com
- https://miner.nimiq.com
- *.nimiq.com
Changes
Tracked since 12 Nov 2026. Last checked 17 minutes ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-34067 | 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 a | Low 3.1 | 22 Apr 2026 |
| CVE-2026-34068 | nimiq-transaction provides the transaction primitive to be used in Nimiq's Rust implementation. Prior to version 1.3.0, the staking contract accepts `UpdateValidator` transactions that set `new_voting_key=Some(...)` while omitting `new_proof_of_knowledge`. this skips the proof-of-knowledge requirement that is needed to prevent BLS rogue-key attacks when public keys are aggregated. Because tendermi | Medium 6.8 | 22 Apr 2026 |
| CVE-2026-34062 | nimiq-libp2p is a Nimiq network implementation based on libp2p. Prior to version 1.3.0, `MessageCodec::read_request` and `read_response` call `read_to_end()` on inbound substreams, so a remote peer can send only a partial frame and keep the substream open. because `Behaviour::new` also sets `with_max_concurrent_streams(1000)`, the node exposes a much larger stalled-slot budget than the library def | Medium 5.3 | 22 Apr 2026 |
| CVE-2026-34063 | Nimiq's network-libp2p is a Nimiq network implementation based on libp2p. Prior to version 1.3.0, `network-libp2p` discovery uses a libp2p `ConnectionHandler` state machine. the handler assumes there is at most one inbound and one outbound discovery substream per connection. if a remote peer opens/negotiate the discovery protocol substream a second time on the same connection, the handler hits a ` | High 7.5 | 22 Apr 2026 |
| CVE-2026-34064 | 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 | Medium 5.3 | 22 Apr 2026 |
| CVE-2026-34065 | 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 call | High 7.5 | 22 Apr 2026 |
| CVE-2026-34066 | 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 `Block | Medium 5.3 | 22 Apr 2026 |
| CVE-2026-33471 | nimiq-block contains block primitives to be used in Nimiq's Rust implementation. `SkipBlockProof::verify` computes its quorum check using `BitSet.len()`, then iterates `BitSet` indices and casts each `usize` index to `u16` (`slot as u16`) for slot lookup. Prior to version 1.3.0, if an attacker can get a `SkipBlockProof` verified where `MultiSignature.signers` contains out-of-range indices spaced b | Critical 9.6 | 22 Apr 2026 |
| CVE-2026-34069 | 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 | Medium 5.3 | 14 Apr 2026 |
| CVE-2026-32605 | 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 reach | High 7.5 | 13 Apr 2026 |
| CVE-2026-40093 | 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 | High 8.1 | 9 Apr 2026 |
| CVE-2026-35468 | 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, two peer-facing consensus request handlers assume that the history index is always available and call blockchain.history_store.history_index().unwrap() directly. That assumption is false by construction. HistoryStoreProxy::history_index() explici | Medium 5.3 | 3 Apr 2026 |
| CVE-2026-33184 | 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, the discovery handler accepts a peer-controlled limit during handshake and stores it unchanged. The immediate HandshakeAck path then honors limit = 0 and returns zero contacts, which makes the session look benign. Later, after the same session re | High 7.5 | 3 Apr 2026 |
| CVE-2026-34061 | 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 elected validator proposer can send an election macro block whose header.interlink does not match the canonical next interlink. Honest validators accept that proposal in verify_macro_block_proposal() because the proposal path validates header | Medium 4.9 | 3 Apr 2026 |
| CVE-2026-28402 | 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.2.2, a malicious or compromised validator that is elected as proposer can publish a macro block proposal where `header.body_root` does not match the actual macro body hash. The proposal can pass proposal verification because the macro proposal verific | High 7.1 | 27 Feb 2026 |