CVE-2026-34066
Assertion Panic in Nimiq Blockchain HistoryStore Causes Denial of Service
Publication date: 2026-04-22
Last updated on: 2026-04-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| nimiq | nimiq_proof-of-stake | to 1.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-20 | The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
| CWE-754 | The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product. |
| CWE-617 | The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability can cause the blockchain node to panic and crash during history synchronization when it receives malformed historic transaction data from a peer. Since the panic happens before rejection checks, it can lead to denial of service by disrupting normal blockchain operations. There are no known workarounds, so affected versions prior to 1.3.0 are vulnerable to such disruptions.
What immediate steps should I take to mitigate this vulnerability?
The immediate step to mitigate this vulnerability is to upgrade nimiq-blockchain to version 1.3.0 or later, where the patch addressing this issue is included.
No known workarounds are available, so upgrading is the recommended action.
Can you explain this vulnerability to me?
The vulnerability exists in the nimiq-blockchain Rust implementation prior to version 1.3.0. Specifically, the function HistoryStore::put_historic_txns uses an assert! statement to enforce that HistoricTransaction.block_number is within certain expected bounds. During history synchronization, a peer can supply a malformed history list that violates these invariants, causing the assert! to trigger a panic. This panic occurs before later rejection checks can run, potentially disrupting the blockchain's operation.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability causes a denial-of-service condition by allowing a malicious peer to crash a syncing node through malformed history data, impacting availability.
There is no impact on confidentiality or integrity, as the vulnerability only affects availability by triggering a panic.
Since the vulnerability does not involve unauthorized data access or data leakage, it does not directly affect compliance with data protection standards such as GDPR or HIPAA, which primarily focus on confidentiality and integrity of personal data.
However, the availability impact could indirectly affect compliance if the denial of service disrupts critical services or data availability requirements mandated by such regulations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a panic (crash) in the Nimiq blockchain node during history synchronization when receiving malformed HistoricTransaction data from a peer.
Detection involves monitoring the node logs for panic events or crashes related to history synchronization, specifically those triggered by assertion failures in the HistoryStore::put_historic_txns function.
Since the vulnerability is triggered by malformed HistoricTransaction objects with invalid block_number values, you can detect attempts by checking logs for warnings or errors about invalid history data or unexpected panics.
No specific network scanning commands or signatures are provided in the resources, but you can monitor the node process for crashes or panics and inspect logs for messages related to history sync failures.
If you have access to the node logs, you might use commands like:
- On Linux, to check for recent panics or crashes in logs: `journalctl -u nimiq-node.service | grep panic` or `grep -i 'history sync' /var/log/nimiq-node.log`
- To monitor the node process for crashes: `systemctl status nimiq-node.service` or `ps aux | grep nimiq` to check if the node is unexpectedly restarting.
Upgrading to version 1.3.0 or later is the recommended mitigation, as it replaces the panic-inducing assert! with error handling that logs warnings and rejects malformed data gracefully.