Nimiq Core CVE-2026-34068

The vulnerability requires two specific conditions: (1) the attacker must successfully submit an UpdateValidator transaction that specifies a new_voting_key without providing new_proof_of_knowledge (this transaction is accepted due to the missing validation check), and (2) the attacker-supplied voting key must be included in the validator set at the time of block justification (requiring prior knowledge of VRF-based validator selection). Non-default configuration is not required; the vulnerability exists in default consensus operation. Exploitation is limited by the cryptographic infeasibility of predicting VRF-selected validator sets, making real-world attacks highly unlikely even with the proof-of-knowledge check absent.

CVSS 6.8 with network vector (AV:N) but high complexity (AC:H) and no confidentiality impact reflects an accurate characterization: the attack is remotely reachable but practically difficult to execute. The critical discrepancy is between CVSS integrity impact (I:H) and the vendor's own assessment that 'exploitability is low.' This disparity is explained by a specific limiting factor: the attacker must predict the VRF-chosen next epoch validator set before it is known, which is cryptographically infeasible. EPSS data not provided, but given active development status (GitHub advisory and patch available), this appears to be a responsibly disclosed vulnerability. The CISA KEV status is not provided in input data, so active exploitation is not confirmed. The vulnerability is genuine and critical from a cryptographic standpoint (signature forgery in consensus), but real-world risk depends heavily on whether an attacker can realistically predict future validator sets. The tags 'JWT Attack' and 'Information Disclosure' appear inconsistent with the BLS rogue-key attack described; JWT is not mentioned in the CVE description, suggesting potential tag misclassification in the source data.

An attacker monitors the Nimiq network and monitors upcoming validator selection through VRF. If the attacker could predict which accounts will be validators in epoch N+1, they could submit an UpdateValidator transaction in epoch N with a crafted voting key designed to enable rogue-key attacks. Upon epoch transition, this key enters the validator set; the attacker then constructs a single BLS signature that, when aggregated with other validators' keys via the vulnerable aggregation logic, appears as a valid multi-signature covering the quorum threshold. This forged justification could be used to justify malicious blocks. However, predicting the VRF output makes this scenario unrealistic in practice.