{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/cpes/cpe2.3akleverklever-go/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:klever:klever-go:*:*:*:*:*:*:*:*"],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["klever-go (\u003c= 1.7.19)"],"_cs_severities":["high"],"_cs_tags":["blockchain","smart-contract","vulnerability","privilege-escalation","klever-go","log-manipulation","unauthenticated-access","websocket-vulnerability"],"_cs_type":"advisory","_cs_vendors":["Klever"],"content_html":"\u003cp\u003eA critical authorization vulnerability (CVE-2026-82405) exists in the \u003ccode\u003eKleverUpdateAccountPermission\u003c/code\u003e built-in function within the \u003ccode\u003eklever-go\u003c/code\u003e repository, affecting versions 1.7.19 and earlier. The vulnerability occurs because the function validates permissions against the \u003ccode\u003evmInput.RecipientAddr\u003c/code\u003e field rather than the authenticated \u003ccode\u003evmInput.CallerAddr\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eIn the context of an indirect smart contract call via \u003ccode\u003eExecuteOnDestContext\u003c/code\u003e, the \u003ccode\u003eRecipientAddr\u003c/code\u003e is determined by the destination contract's chosen \u003ccode\u003edest\u003c/code\u003e argument, which an attacker can manipulate. Because most accounts are configured as their own signers by default, the permission check incorrectly returns \u003ccode\u003etrue\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker deploys a malicious smart contract to the blockchain.\u003c/li\u003e\n\u003cli\u003eAttacker initiates an \u003ccode\u003eExecuteOnDestContext\u003c/code\u003e call from their malicious contract.\u003c/li\u003e\n\u003cli\u003eAttacker sets the \u003ccode\u003edest\u003c/code\u003e argument to the victim account address (V).\u003c/li\u003e\n\u003cli\u003eThe VM dispatch mechanism \u003ccode\u003eprepareIndirectContractCallInput\u003c/code\u003e sets \u003ccode\u003eRecipientAddr\u003c/code\u003e to V and \u003ccode\u003eCallerAddr\u003c/code\u003e to the attacker's contract.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eKleverUpdateAccountPermission\u003c/code\u003e handler receives the call and executes \u003ccode\u003econtractHasValidPermission\u003c/code\u003e using the attacker-controlled \u003ccode\u003eRecipientAddr\u003c/code\u003e (V).\u003c/li\u003e\n\u003cli\u003eThe check compares V against V's own signers, which inherently grants permission for the Owner type.\u003c/li\u003e\n\u003cli\u003eThe VM proceeds to \u003ccode\u003eUpdatePermission\u003c/code\u003e, replacing V's original account permissions with attacker-supplied signers.\u003c/li\u003e\n\u003cli\u003eAttacker gains full control over the victim account, enabling asset theft or account lock.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cp\u003ePatch the \u003ccode\u003eKleverUpdateAccountPermission\u003c/code\u003e handler to validate authorization against \u003ccode\u003evmInput.CallerAddr\u003c/code\u003e instead of \u003ccode\u003evmInput.RecipientAddr\u003c/code\u003e.\nUpdate \u003ccode\u003eklever-go\u003c/code\u003e to a version containing the fix for CVE-2026-82405.\nReview all smart contract built-in function handlers in the \u003ccode\u003eklever-go\u003c/code\u003e codebase for similar authorization discrepancies between \u003ccode\u003eRecipientAddr\u003c/code\u003e and \u003ccode\u003eCallerAddr\u003c/code\u003e.\nImplement logic to require the target account address in \u003ccode\u003eArguments[0]\u003c/code\u003e to match the authenticated caller or a legitimately authorized entity.\u003c/p\u003e\n","date_modified":"2026-09-23T19:57:14Z","date_published":"2026-09-23T19:57:00Z","id":"https://feed.craftedsignal.io/briefs/2026-09-klever-vm-auth-bypass/","summary":"An authorization flaw in the Klever-Go VM allows attackers to execute an account takeover by leveraging an incorrectly validated RecipientAddr parameter during indirect smart contract calls.","title":"Authorization Bypass in Klever-Go KleverUpdateAccountPermission Built-in","url":"https://feed.craftedsignal.io/briefs/2026-09-klever-vm-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - Cpe:2.3:a:klever:klever-Go:*:*:*:*:*:*:*:*","version":"https://jsonfeed.org/version/1.1"}