CVE-2026-82405: Klever-Go Privilege Escalation Vulnerability

CVE-2026-82405 Overview

Klever-Go, the Go implementation of the Klever blockchain protocol, contains an authorization flaw in its KleverUpdateAccountPermission built-in function. Prior to version 1.7.20, the function authorizes permission replacement by checking the attacker-controlled vmInput.RecipientAddr instead of the authenticated vmInput.CallerAddr. An attacker-controlled smart contract can select any victim account with configured permissions as the recipient and pass authorization using the victim's default self-signer. This allows overwriting the victim's Owner permissions with attacker-supplied values. The flaw is categorized as an incorrect authorization weakness [CWE-863].

Critical Impact
An attacker can replace a victim account's entire permission set without possessing any victim key or signature, enabling asset theft or permanent account lockout.

Affected Products

Klever-Go blockchain node software prior to version 1.7.20
Smart contract execution paths invoking KleverUpdateAccountPermission
Accounts with stored permissions on the Klever network

Discovery Timeline

2026-09-23 - CVE-2026-82405 published to the National Vulnerability Database
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-82405

Vulnerability Analysis

The vulnerability resides in the KleverUpdateAccountPermission built-in function within the Klever-Go virtual machine. When invoked from a smart contract, the function must verify that the caller has authority to modify the target account's permissions. Instead, the implementation performs its authorization check against vmInput.RecipientAddr, a value the caller controls.

The helper contractHasValidPermission then evaluates the recipient account's own signers. Because most accounts include a default self-signer meeting the Owner threshold, the check trivially succeeds. Once authorization returns true, UpdatePermission proceeds to replace the victim's entire permission set with attacker-supplied Owner permissions.

The native transaction path and accounts without stored permissions are not affected. The scope is limited to smart-contract-invoked permission updates against accounts that have previously configured permissions.

Root Cause

The root cause is confusion between the authenticated caller and the operation target. Standard secure design requires authorization decisions to be tied to the authenticated principal, vmInput.CallerAddr. The vulnerable code instead consults vmInput.RecipientAddr, effectively letting the caller nominate whose signers should authorize the change.

Attack Vector

An attacker deploys or controls a smart contract and invokes KleverUpdateAccountPermission with the victim address as RecipientAddr and a crafted UpdateAccountPermissionContract payload defining new Owner permissions. The chain accepts the operation, replacing the victim's Owner set with attacker-controlled signers. The attacker can then drain assets or configure permissions so no legitimate key can transact.

// Security patch: authorize permission update against caller, not recipient
// core/kapp/accounts/accounts.go
func authorizerCanUpdatePermission(permissions []*state.Permission, authorizer []byte) bool {
    for _, permission := range permissions {
        for _, signer := range permission.Signers {
            if !bytes.Equal(signer.Address, authorizer) {
                continue
            }

            if signer.Weight >= permission.Threshold &&
                permission.CheckPermissionGrantedForContracts(transaction.TXContract_UpdateAccountPermissionContractType) {
                return true
            }
        }
    }

    return false
}

func (a *accountsKapp) UpdatePermission(authorizer []byte, target []byte, tc *transaction.UpdateAccountPermissionContract) (transaction.Transaction_TXResultCode, error) {
    // ...
}

Source: GitHub Commit c58740e

Detection Methods for CVE-2026-82405

Indicators of Compromise

Successful UpdateAccountPermissionContract transactions where the invoking contract's caller address differs from the account whose permissions were modified.
On-chain account state changes replacing Owner signers with previously unseen addresses.
Sudden loss of transaction signing ability by legitimate account owners immediately following a contract call.

Detection Strategies

Audit historical blocks for KleverUpdateAccountPermission built-in invocations originating from smart contracts and compare CallerAddr against the affected account.
Alert on any permission-set replacement where the new Owner signers do not overlap with prior signers.
Correlate contract deployment events with subsequent permission modifications targeting high-value accounts.

Monitoring Recommendations

Ingest Klever node event logs into a centralized data lake and index by account address, contract type, and caller.
Track baseline patterns of permission updates per account and flag deviations for review.
Monitor upgrade compliance across validator and RPC nodes to confirm all endpoints run version 1.7.20 or later.

How to Mitigate CVE-2026-82405

Immediate Actions Required

Upgrade all Klever-Go nodes to version 1.7.20, which contains the authorization fix.
Review recent permission changes on accounts with stored permissions and validate legitimacy with account owners.
Rotate Owner permissions on any account suspected of unauthorized modification and reassess signer weights and thresholds.

Patch Information

The fix is available in Klever-Go release v1.7.20. The patch introduces authorizerCanUpdatePermission and changes UpdatePermission to receive both an authorizer and a target, ensuring authorization is checked against the authenticated caller. See the GitHub Security Advisory GHSA-97cv-x867-6xhm for full details.

Workarounds

If immediate upgrade is not possible, restrict smart contract deployment and execution on affected nodes until patching is complete.
Advise users to avoid configuring named permissions on high-value accounts until nodes are updated, since accounts without stored permissions are not affected.
Use the native transaction path for permission changes instead of contract-mediated calls.

bash

# Upgrade Klever-Go node to patched release
git clone https://github.com/klever-io/klever-go.git
cd klever-go
git checkout v1.7.20
make build

# Verify running version before restarting validator
./klever-go --version