CVE-2026-46545: Nimiq State Sync Denial-of-Service Vulnerability (CVSS 7.5)
Nimiq, a blockchain implementation using Rust, contains a vulnerability that allows remote attackers to crash nodes that are synchronizing state data from the network. This affects newly joining nodes and nodes recovering from downtime. The issue stems from improper handling of data chunks during state synchronization, enabling any peer on the network to send malicious input that triggers a denial-of-service condition. The vulnerability has been resolved in version 1.5.0.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-248
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-10 / 2026-06-17
NVD description (verbatim)
Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.5.0, a remote, unauthenticated denial-of-service vulnerability in MerkleRadixTrie::put_chunk allows any state-sync peer to crash any node performing state synchronization (freshly joining nodes and recovering nodes). This issue has been patched in version 1.5.0.
3 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-46545 is a remote denial-of-service vulnerability in the MerkleRadixTrie::put_chunk function within Nimiq's state synchronization logic. The vulnerability allows unauthenticated network peers to cause unhandled exceptions or resource exhaustion in nodes performing state sync operations. The root cause relates to insufficient validation or error handling (CWE-248: Uncaught Exception) when processing merkle trie chunk data during the synchronization protocol. Attackers need only network access to the vulnerable node and no prior authentication or special privileges. The CVSS 3.1 score of 7.5 reflects high availability impact with low attack complexity.
Business impact
For organizations running Nimiq nodes, this vulnerability creates operational risk during critical node lifecycle events. Newly deployed nodes cannot reliably complete state synchronization—a core bootstrapping requirement—making network participation unpredictable. Node recovery scenarios are similarly compromised, extending outage windows and complicating disaster recovery procedures. If multiple nodes in a validator set or infrastructure deployment are affected simultaneously, network participation and consensus contribution become unreliable, potentially impacting service availability and stake distribution.
Affected systems
All Nimiq implementations prior to version 1.5.0 are affected. This includes nodes running the Albatross consensus algorithm-based Proof-of-Stake protocol. The vulnerability specifically impacts nodes in active state synchronization: freshly joined nodes bootstrapping from genesis or a checkpoint, and recovering nodes re-syncing after downtime or network partitions. Nodes that have already completed state synchronization and are operating in steady state may not be immediately exploitable via this vector, though network-wide attacks could target multiple nodes simultaneously during any sync phase.
Exploitability
This vulnerability is trivial to exploit and requires no specialized privileges or credentials. Any network peer with connectivity to a vulnerable node can send a crafted state sync chunk that triggers the crash. The attack surface is broad because state synchronization is a normal, expected operation for nodes joining or recovering on the Nimiq network. An attacker need only craft a malicious merkle trie chunk and send it during the state sync protocol handshake—low technical barrier. The lack of authentication or complexity in the consensus protocol itself means an attacker can perform reconnaissance and identify vulnerable nodes passively before launching attacks.
Remediation
Upgrade all Nimiq nodes to version 1.5.0 or later. This release includes fixes to the MerkleRadixTrie::put_chunk function to properly validate and handle malformed or unexpected chunk data. Organizations should prioritize upgrading nodes that are frequently performing state synchronization (such as those in test environments, recovering deployments, or running lightweight/validator infrastructure). Verify that upgrades complete successfully and that nodes can complete state synchronization without interruption before returning them to production consensus participation.
Patch guidance
Obtain version 1.5.0 or later from the official Nimiq repository or release channels. Review the release notes to confirm the fix addresses CVE-2026-46545 and any related state-sync robustness improvements. Before deploying to production validators or critical nodes, test the upgrade in a staging environment where you can trigger state synchronization and confirm smooth operation. Plan upgrades during low-load periods or outside critical consensus windows if possible. Nodes do not require data migration or configuration changes—the upgrade is straightforward. Verify node connectivity and state synchronization completion after upgrade; monitor logs for any sync-related errors.
Detection guidance
Monitor for nodes experiencing unexpected crashes or panics during state synchronization phases, particularly correlated with new node deployments or recovery operations. Log analysis should flag any MerkleRadixTrie or state-sync panic messages. Network-level detection is challenging without deep protocol inspection, but you can monitor for peers sending unusual state sync requests or chunks to your nodes and cross-reference with known peer reputations. Implement alerting for nodes that repeatedly fail to complete state synchronization within expected timeframes, as this may indicate active exploitation attempts. Temporary mitigation includes restricting state-sync peer connections to whitelisted, trusted peers if feasible, though this reduces network resilience.
Why prioritize this
This vulnerability warrants prompt remediation despite not being on the KEV catalog. The combination of remote exploitability, no authentication required, high attack surface (all state-syncing nodes), and direct availability impact make it a clear operational risk. The attack is trivial to execute and could be weaponized at scale to disrupt network participation or target specific validator infrastructure. Nodes cannot safely perform state synchronization until patched, directly blocking normal lifecycle operations. High CVSS score and practical exploitability justify treating this as urgent.
Risk score, explained
The CVSS 3.1 score of 7.5 (HIGH) reflects: Network-accessible attack vector (AV:N), low attack complexity requiring no special conditions (AC:L), no privilege requirement (PR:N), no user interaction needed (UI:N), and high impact to availability (A:H). Confidentiality and integrity are not affected (C:N/I:N). The score appropriately captures the operational threat to node availability during state synchronization without overweighting attack complexity, which is minimal for a network-based DoS.
Frequently asked questions
Will this vulnerability affect my node if state synchronization is already complete?
Nodes in steady state operation after completing initial state synchronization are less immediately vulnerable to this specific vector, since the MerkleRadixTrie::put_chunk function is primarily active during the state-sync process. However, any recovery, re-sync, or state rebuild could re-expose the node. Upgrade to 1.5.0 regardless to eliminate the risk entirely.
Can I mitigate this without upgrading by restricting my peer connections?
Temporarily restricting state-sync peers to a whitelist of trusted nodes you control may reduce exposure, but this degrades network resilience and does not eliminate risk if any trusted peer is compromised or misconfigured. Mitigation is not a substitute for patching—upgrade to 1.5.0 as soon as feasible.
Does this vulnerability require me to re-sync my entire blockchain state?
No. The patch applies to how state chunks are validated during synchronization. Existing blockchain state stored on disk does not require rebuilding. After upgrading, your node will resume or restart state synchronization using the improved validation logic.
Are there version branches or distributions of Nimiq that have backported this fix?
Verify against the official Nimiq advisory and release notes. Version 1.5.0 is confirmed to contain the fix. Do not assume backports exist—always upgrade to the recommended version unless your distribution explicitly documents a backport in an earlier release.
This analysis is based on publicly available vulnerability data and official vendor guidance current as of the publication date. Exploit code, proof-of-concept demonstrations, and weaponized attack details are not provided in this advisory. Organizations should verify all patch versions, CVE mappings, and affected product lists against authoritative vendor resources before making remediation decisions. The presence or absence of a vulnerability on threat intelligence feeds (such as CISA KEV) does not indicate severity or exploit prevalence; independent risk assessment is recommended. This advisory does not constitute security advice for any specific deployment—consult with your infrastructure and security teams before applying patches to production systems. Source: NVD (public-domain), retrieved 2026-07-19. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2026-45685HIGHOpenTelemetry eBPF Instrumentation MongoDB Parser DoS (v0.1.0–0.8.x)
- CVE-2026-45554MEDIUMNiceGUI Static Asset Route Log Flooding Vulnerability
- CVE-2026-45676MEDIUMOpenTelemetry eBPF Instrumentation ELF Parser Denial of Service
- CVE-2026-46411MEDIUMFlashMQ Authentication DoS via Write Buffer Overflow
- CVE-2016-20062HIGHSQL Injection in Simply Poll 1.4.1 WordPress Plugin - Unauthenticated Data Theft
- CVE-2016-20063HIGHSQL Injection in Single Personal Message 1.0.3 – Credential & Data Theft Risk
- CVE-2016-20065HIGHUnauthenticated SQL Injection in Product Catalog 8 WordPress Plugin
- CVE-2017-20243HIGHWordPress Car Park Booking Plugin SQL Injection Vulnerability