CVE-2026-82405: Incorrect Authorization leading to Account Takeover in klever-go

The Go implementation of the Klever blockchain protocol (klever-go) contains a critical incorrect authorization vulnerability within its Virtual Machine execution layer. The flaw resides specifically in the KleverUpdateAccountPermission VM built-in function. This function is responsible for managing and modifying cryptographic authorization structures and permissions for user accounts on the blockchain network.

This security vulnerability belongs to the Incorrect Authorization class (CWE-863). During VM execution, the system fails to correctly verify whether the entity invoking the permission modification has the required cryptographic authority to perform the action. Instead, the validation checks rely on an attacker-controlled variable rather than the authenticated transaction caller.

Successful exploitation of this flaw allows an unauthenticated remote attacker to completely overwrite the permission structure of a target wallet. This enables a complete account takeover, leading to the unauthorized transfer of assets and permanent lockout of the legitimate owner. The vulnerability exposes a critical attack surface in the protocol's smart contract execution environment.

The root cause of the vulnerability resides within the authorization check in core/kapp/builtInFunctions/kleverUpdateAccountPermission.go. When a contract triggers the ProcessBuiltinFunction method, the virtual machine loads the target account data into memory. It then invokes the internal helper method contractHasValidPermission to determine whether the transaction execution is authorized.

This helper method validates authorization by comparing registered signers in the target account with the vmInput.RecipientAddr parameter. However, in the context of indirect contract calls, the calling contract controls both the parameters of the call and the value of vmInput.RecipientAddr. Because of this design choice, the target value is entirely under the control of the attacker's execution payload.

By setting vmInput.RecipientAddr to match the target victim's account address, the attacker forces the comparison bytes.Equal(signer.Address, recipientAddr) to evaluate as true. The validation checks identify the victim's self-signing entry and accept its weight as valid authorization. The virtual machine then proceeds to execute the state change without verifying that the actual transaction caller has any authorization over the victim account.

Prior to the patch, the vulnerable helper function evaluated permissions using the uncontrolled recipient address as shown below:

func (e *kleverUpdateAccountPermission) contractHasValidPermission(permissions []*state.Permission, recipientAddr []byte) bool {
    for _, permission := range permissions {
        for _, signer := range permission.Signers {
            if !bytes.Equal(signer.Address, recipientAddr) {
                continue
            }
            if signer.Weight >= permission.Threshold &&
                permission.CheckPermissionGrantedForContracts(transaction.TXContract_UpdateAccountPermissionContractType) {
                return true
            }
        }
    }
    return false
}

The security patch resolved this flaw in commit c58740eb74d7ee8f07db1e18a7d6214b5559ba32 by removing the vulnerable helper and passing the authenticated CallerAddr directly to the KApp core:

// Updated call structure passing caller address explicitly
resultCode, err := e.kappController.GetAccountsKApp().UpdatePermission(vmInput.CallerAddr, address, contract)

The core KApp function signature was hardened to ensure that permissions can only be updated if the cryptographically verified authorizer matches the target account, or is explicitly registered as an authorized delegate in the permission state:

func (a *accountsKapp) UpdatePermission(authorizer []byte, target []byte, tc *transaction.UpdateAccountPermissionContract) (transaction.Transaction_TXResultCode, error) {
    ...
    if !bytes.Equal(authorizer, target) && !authorizerCanUpdatePermission(ownerAcc.GetPermissions(), authorizer) {
        ctx.Receipts().AddError(ctx.ContractID(), common.ErrFieldInvalidPermission, common.ErrNoPermission.Error())
        return transaction.Transaction_ParameterInvalid, common.ErrNoPermission
    }
    ...
}

To execute this attack, an adversary deploys a malicious smart contract on the target network. This smart contract is configured to trigger the KleverUpdateAccountPermission built-in function via an indirect call. The attack payload specifies the target victim's wallet address as the subject of the permission change.

The exploit sequence operates as follows:

The malicious contract sets the RecipientAddr parameter of the indirect call payload to the victim's account address. When the built-in function processes this input, it locates the victim's own self-signing key within their permission structure. Because the addresses match, the validator confirms that the self-signer key meets the threshold and approves the modification, replacing the legitimate key with the attacker's public key.

The impact of CVE-2026-82405 is critical to the security and integrity of the affected blockchain network. Successful exploitation allows an attacker to seize absolute control of any account on the network that has previously configured custom permissions. Legitimate users are locked out of their accounts because their active keys are deleted from the account's state.

With administrative access established, the attacker can transfer all tokens, interact with contracts as the victim, and modify secondary security settings. This bypasses multi-signature configurations entirely, rendering advanced account protection mechanisms ineffective. This poses a severe threat to decentralized organizations, validators, and individual participants.

The primary remediation for this vulnerability is to upgrade all klever-go nodes, validators, and client software to version 1.7.20 or later. This release contains the formal patch that replaces the vulnerable validation checks with a robust identity check. Users should review their account permission configurations to ensure no unexpected changes occurred prior to patching.

In environments where immediate software upgrades are not feasible, network administrators should implement logging and monitoring controls to capture and analyze call parameters to the UpdateAccountPermission built-in contract. Any pattern of contract-initiated permission updates targeting separate user addresses should be treated as a highly critical security incident.