CVE-2026-34068: Nimiq Transaction Privilege Escalation

CVE-2026-34068 Overview

CVE-2026-34068 is a cryptographic vulnerability in the nimiq-transaction component of Nimiq's Rust implementation (core-rs-albatross). The vulnerability exists in the staking contract's validator update functionality, where UpdateValidator transactions can set a new voting key without providing the required proof-of-knowledge. This bypass enables BLS rogue-key attacks when validator public keys are aggregated during Tendermint macro block justification verification.

Critical Impact

An attacker could potentially forge quorum-looking block justifications using a single malicious signature by exploiting the missing proof-of-knowledge validation during voting key updates.

Affected Products

• nimiq-transaction (Nimiq Core-rs-albatross) versions prior to v1.3.0
• Nimiq blockchain nodes running vulnerable staking contract implementations
• Systems utilizing BLS signature aggregation without proper key validation

Discovery Timeline

• 2026-04-22 - CVE CVE-2026-34068 published to NVD
• 2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-34068

Vulnerability Analysis

The vulnerability stems from improper verification of cryptographic signatures (CWE-347) in the validator update transaction processing logic. The staking contract's handling of UpdateValidator transactions fails to enforce the proof-of-knowledge requirement when a new voting key is provided. This oversight allows an attacker to register a voting key without demonstrating knowledge of the corresponding private key.

In BLS signature schemes used by blockchain consensus protocols, proof-of-knowledge is essential to prevent rogue-key attacks. When multiple BLS public keys are aggregated (as occurs during Tendermint macro block justification verification), an attacker with a carefully crafted rogue public key can produce a valid-looking aggregated signature without cooperation from other validators. The attack works by choosing a public key that mathematically cancels out the contributions of legitimate validators in the aggregate.

While the potential impact is severe—allowing forged block justifications—the exploitability is constrained by practical factors. The voting keys are fixed for each epoch, and an attacker would need advance knowledge of the validator set for the next epoch, which is determined through a Verifiable Random Function (VRF) and is therefore unpredictable.

Root Cause

The root cause lies in the conditional validation logic within primitives/transaction/src/account/staking_contract/structs.rs. The original code only performed proof-of-knowledge verification when bothnew_voting_key and new_proof_of_knowledge were provided as Some(...) values. This allowed transactions with new_voting_key=Some(...) and new_proof_of_knowledge=None to bypass the validation entirely, creating a window for rogue-key injection.

Attack Vector

The attack exploits the network-accessible staking contract interface through the following mechanism:

1. Attacker constructs an UpdateValidator transaction with a malicious voting key
2. Transaction omits the new_proof_of_knowledge field (sets it to None)
3. Staking contract accepts the transaction without validating key ownership
4. Malicious key enters the validator set for the epoch
5. During block justification, attacker can craft signatures that appear valid when aggregated

The actual security patch demonstrates the proper validation approach:

                // Check proof of knowledge, if necessary.
-                if let (Some(new_voting_key), Some(new_proof_of_knowledge)) =
-                    (new_voting_key, new_proof_of_knowledge)
-                {
-                    verify_proof_of_knowledge(new_voting_key, new_proof_of_knowledge)?;
+                match (new_voting_key, new_proof_of_knowledge) {
+                    (Some(key), Some(pok)) => verify_proof_of_knowledge(key, pok)?,
+                    (Some(_), None) => return Err(TransactionError::InvalidData),
+                    (None, Some(_)) => return Err(TransactionError::InvalidData),
+                    (None, None) => {} // no key change, nothing to verify
                }

                // Check that the signature is correct.

Source: GitHub Commit Update

Detection Methods for CVE-2026-34068

Indicators of Compromise

• UpdateValidator transactions with new_voting_key present but missing new_proof_of_knowledge
• Unusual validator key registrations without corresponding proof-of-knowledge submissions
• Block justifications that fail independent signature verification despite appearing valid in aggregate

Detection Strategies

• Implement transaction validation auditing to flag UpdateValidator calls with incomplete key/proof pairs
• Monitor staking contract events for validator updates and cross-reference with proof-of-knowledge submissions
• Deploy signature verification tests that validate individual validator contributions rather than only aggregated signatures

Monitoring Recommendations

• Enable verbose logging on staking contract transaction processing
• Set up alerts for any TransactionError::InvalidData responses from validator update operations
• Periodically audit the validator set for keys that lack corresponding proof-of-knowledge records in on-chain history

How to Mitigate CVE-2026-34068

Immediate Actions Required

• Upgrade to nimiq-core-rs-albatross version v1.3.0 or later immediately
• Audit existing validator registrations to ensure all voting keys have valid proof-of-knowledge records
• Review any UpdateValidator transactions processed prior to the upgrade for potential exploitation

Patch Information

The vulnerability has been addressed in version v1.3.0 of nimiq-core-rs-albatross. The patch modifies the conditional validation in primitives/transaction/src/account/staking_contract/structs.rs to use exhaustive pattern matching, ensuring that:

• Transactions with a new voting key MUST include proof-of-knowledge
• Transactions with proof-of-knowledge but no new key are rejected
• Only transactions with neither or both fields are permitted

For detailed patch information, see the GitHub Pull Request and GitHub Security Advisory.

Workarounds

• No known workarounds are available according to the vendor advisory
• Upgrading to version v1.3.0 or later is the only recommended remediation
• Operators unable to immediately upgrade should increase monitoring of validator update transactions

# Upgrade to patched version
git fetch --tags
git checkout v1.3.0
cargo build --release