CVE-2026-46540: Nimiq Light Client State Synchronization Vulnerability

Technical summary

CVE-2026-46540 is a state management inconsistency in Nimiq's LightBlockchain::rebranch() method. When rebranching to a fork whose tip is a macro block, the method updates self.head but fails to synchronously update self.macro_head, self.election_head, self.current_validators, and the chain_store's election header record. This diverges from the correct behavior in Blockchain::rebranch() (blockchain/src/blockchain/push.rs:504-518), which atomically updates all macro and election state during a rebranch to a macro block. Consequently, subsequent block verification uses stale state: macro blocks are verified against an incorrect predecessor via verify_macro_successor(&this.macro_head), and if the rebranch target was an election block, all subsequent blocks fail validator verification via verify_validators(), halting chain progression. The root cause is inadequate state synchronization in the light client's fork adoption logic.

Business impact

Light client deployments using Nimiq prior to version 1.4.0 are at risk of service disruption. If an attacker or network partition causes a light client to adopt a fork terminating in a macro block, the client's consensus state becomes inconsistent. In the worst case—when the fork tip is an election block—the light client will reject all subsequent blocks and cannot recover without manual intervention or a restart. This prevents the light client from processing new transactions or maintaining a synchronized view of the blockchain, effectively rendering it unavailable. Full nodes are unaffected. The impact is availability-focused; data integrity is not directly compromised, but clients may become unable to validate transactions or synchronize the chain.

Affected systems

Nimiq light clients in versions prior to 1.4.0 are vulnerable. Light clients are typically deployed in resource-constrained environments such as mobile wallets, web browsers, or IoT devices that do not store the full blockchain. Full Nimiq nodes (which run the complete Blockchain implementation, not LightBlockchain) are not affected because they correctly update all consensus state during rebranching. The vulnerability does not affect Nimiq's core protocol or consensus security on full nodes; it is specific to the light client implementation.

Exploitability

The vulnerability requires an attacker or network condition to cause a light client to adopt a fork whose chain tip is a macro block. This could occur through a network partition, Eclipse attack targeting a light client, or coordinated fork propagation by malicious nodes. The attack does not require authentication, special privileges, or user interaction beyond normal light client operation. However, triggering the exact failure condition—a fork adoption with a macro block tip—may require sustained network manipulation or favorable timing during network consensus. Once triggered, the impact is deterministic: the light client's state becomes inconsistent and blocks are either rejected or the client stalls.

Remediation

Upgrade to Nimiq version 1.4.0 or later. The patch ensures that LightBlockchain::rebranch() atomically updates self.head, self.macro_head, self.election_head, self.current_validators, and the chain_store's election header when adopting a fork with a macro block tip, aligning the light client's behavior with the full node implementation. No data migration or manual recovery is needed; the upgrade takes effect on next restart.

Patch guidance

Apply the upgrade to Nimiq version 1.4.0 or later as soon as feasible. Light client operators—including mobile wallet providers, browser-based wallet services, and embedded blockchain clients—should prioritize this update because light clients are the primary attack surface. The patch is backward-compatible at the protocol level. Test the upgrade in a non-production environment first to ensure compatibility with any custom integrations or middleware. If you operate a full Nimiq node, this CVE does not affect you, but you may want to update for alignment with the latest codebase.

Detection guidance

Monitor light client logs for unusual patterns: repeated block rejections with 'validator verification failed' errors, or persistent chain synchronization failures after a fork detection event. Network monitoring can detect fork propagation events; correlate these with light client anomalies. If a light client stops advancing its chain head after a rebranch event (especially following a detected fork), suspect this vulnerability. Post-incident, review the light client's recorded chain state to identify whether the last rebranch occurred at a macro block and whether macro_head and head diverged. For proactive monitoring, maintain parity checks between light client state snapshots and reference full node state.

Why prioritize this

This is a CVSS 6.5 MEDIUM severity issue that directly impacts availability of light clients in production use. While not a critical protocol vulnerability affecting consensus security on full nodes, light clients are widely deployed in mobile and web wallets that serve end-user transactions. A stalled light client can freeze transaction processing and user access to blockchain services. The exploitability is moderate—it requires specific network conditions or a coordinated attack—but the impact is high for affected clients. Organizations operating light client infrastructure should treat this as a high-priority patch. Organizations running only full nodes can deprioritize unless they also distribute light client software.

Risk score, explained

The CVSS 6.5 score reflects MEDIUM severity: network-accessible attack vector (AV:N), low attack complexity (AC:L), no privileges or user interaction required (PR:N/UI:N), no confidentiality impact (C:N), but both integrity (I:L) and availability (A:L) impacts. The integrity impact stems from the client's inability to correctly validate the blockchain state post-rebranch; the availability impact is the potential service disruption. The score does not escalate higher because the vulnerability is confined to light clients, the attack requires specific triggering conditions, and confidentiality is not compromised.

Frequently asked questions