What is the CVSS score of CVE-2026-46540?

CVE-2026-46540 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L. EPSS exploitation probability: 0.0%.

Nimiq Albatross CVE-2026-46540

MEDIUM

Improper Enforcement of Behavioral Workflow (CWE-841)

2026-06-10 security-advisories@github.com

Information Disclosure Checkpoint

6.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jun 10, 2026 - 00:46 vuln.today

Analysis Generated

Jun 10, 2026 - 00:46 vuln.today

DescriptionNVD

Nimiq is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.4.0, when LightBlockchain::rebranch() adopts a fork chain whose tip is a macro block (checkpoint or election), it only updates self.head but fails to update self.macro_head, self.election_head, self.current_validators, or store the election header in the chain_store. This is in direct contrast with the full Blockchain::rebranch() at blockchain/src/blockchain/push.rs:504-518, which correctly updates all macro/election state when the new head is a macro block. After a rebranch to a macro block, the stale macro_head causes subsequent macro blocks pushed via push() to be verified against the wrong predecessor via verify_macro_successor(&this.macro_head). If the rebranch target was an election block, the stale current_validators causes every subsequent block to fail verify_validators(), completely stalling the light client's chain progression. This issue has been patched in version 1.4.0.

AnalysisAI

Incomplete macro-block state synchronization in Nimiq core-rs-albatross LightBlockchain allows a network-accessible attacker to permanently stall a light client's chain progression by triggering a rebranch to a fork whose tip is a macro (checkpoint or election) block. Affected are all deployments of the Rust Albatross light client prior to v1.4.0. When exploitation targets an election block specifically, the stale current_validators pointer causes every subsequent push() call to fail verify_validators(), rendering the light client unable to advance its chain. No public exploit identified at time of analysis, though the exact fix is visible in merged PR #3706 and the triggering conditions are fully described in the advisory.

Technical ContextAI

Nimiq's Albatross proof-of-stake consensus distinguishes micro blocks from macro blocks; macro blocks are further split into checkpoint blocks (batch boundaries) and election blocks (epoch boundaries). Election blocks carry the validator set for the next epoch. The LightBlockchain struct maintains four distinct state pointers: head (current chain tip), macro_head (most recent macro block), election_head (most recent election block), and current_validators (active validator set derived from the last election). When a rebranch occurs (the light client switches from its current chain to a superior fork), the rebranch() function must update all four pointers if the new chain tip is a macro block. Prior to v1.4.0, the implementation in light-blockchain/src/push.rs updated only self.head, leaving macro_head, election_head, current_validators, and the chain_store's election record in a stale state. CWE-841 (Improper Enforcement of Behavioral Workflow) precisely captures the root cause: the full Blockchain::rebranch() at blockchain/src/blockchain/push.rs:504-518 correctly performs all macro-state updates, but the light client's parallel implementation omitted this branch of logic. The affected CPE is the Rust crate nimiq/core-rs-albatross versions prior to 1.4.0.

Affected ProductsAI

All deployments of the Nimiq core-rs-albatross Rust implementation using the LightBlockchain component prior to version 1.4.0 are affected. Full nodes using Blockchain::rebranch() are not affected by this logic gap. The patched release is tagged v1.4.0, confirmed at https://github.com/nimiq/core-rs-albatross/releases/tag/v1.4.0. The GitHub Security Advisory is GHSA-m3pg-qc2q-mg8c, accessible at https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-m3pg-qc2q-mg8c. No CPE string was provided in NVD at time of analysis; the affected software is identifiable as the nimiq/core-rs-albatross crate on crates.io prior to 1.4.0.

RemediationAI

Upgrade to Nimiq core-rs-albatross v1.4.0, the vendor-released patch confirmed by the GitHub release tag at https://github.com/nimiq/core-rs-albatross/releases/tag/v1.4.0. The fix, implemented in PR #3706 (https://github.com/nimiq/core-rs-albatross/pull/3706), adds a conditional block in light-blockchain/src/push.rs that detects when the new head after a rebranch is a macro block and explicitly updates macro_head, election_head, current_validators, and writes the election header to chain_store - mirroring the already-correct logic in the full Blockchain::rebranch(). If an immediate upgrade is not possible, operators running light clients may consider switching to full node mode, which uses the unaffected Blockchain::rebranch() path; this trades reduced resource usage for correctness and is the only reliable compensating control, as no configuration flag exists to disable the vulnerable rebranch path selectively. There is no known in-process workaround that preserves light-client mode while preventing the stale-state corruption.