In the context of an indirect smart contract call via ExecuteOnDestContext, the RecipientAddr is determined by the destination contract's chosen dest argument, which an attacker can manipulate. Because most accounts are configured as their own signers by default, the permission check incorrectly returns true when the attacker specifies the target account as the recipient. This allows an attacker to overwrite the entire permission set of any target account with their own malicious keys, resulting in a full account takeover. The issue is restricted to calls originating from smart contracts, as the native transaction path correctly validates senders.

Attack Chain

1. Attacker deploys a malicious smart contract to the blockchain.
2. Attacker initiates an ExecuteOnDestContext call from their malicious contract.
3. Attacker sets the dest argument to the victim account address (V).
4. The VM dispatch mechanism prepareIndirectContractCallInput sets RecipientAddr to V and CallerAddr to the attacker's contract.
5. The KleverUpdateAccountPermission handler receives the call and executes contractHasValidPermission using the attacker-controlled RecipientAddr (V).
6. The check compares V against V's own signers, which inherently grants permission for the Owner type.
7. The VM proceeds to UpdatePermission, replacing V's original account permissions with attacker-supplied signers.
8. Attacker gains full control over the victim account, enabling asset theft or account lock.

Impact

Successful exploitation results in the complete compromise of any account with configured permissions on the Klever blockchain. Victims include multisig and advanced-permission accounts. Attackers can evict original owners and gain full control over all operations associated with the victim's address, leading to irreversible loss of funds or total account lockout.

Recommendation

Patch the KleverUpdateAccountPermission handler to validate authorization against vmInput.CallerAddr instead of vmInput.RecipientAddr. Update klever-go to a version containing the fix for CVE-2026-82405. Review all smart contract built-in function handlers in the klever-go codebase for similar authorization discrepancies between RecipientAddr and CallerAddr. Implement logic to require the target account address in Arguments[0] to match the authenticated caller or a legitimately authorized entity.