Klever Go
Monthly
Account takeover in Klever-Go's KleverUpdateAccountPermission built-in (all versions prior to 1.7.20) allows an attacker-controlled smart contract to replace a victim account's entire permission set without any victim key or signature. The handler authorizes updates using the attacker-supplied vmInput.RecipientAddr instead of the authenticated vmInput.CallerAddr, and because the default self-signer created by createDefaultOwnerPermission satisfies the contractHasValidPermission check, a contract can name any permissioned victim as recipient and install attacker-supplied Owner permissions - enabling asset theft or permanent lockout of the victim. The CVSS 4.0 score is 8.7 with a low-privilege vector (PR:L), reflecting that the attacker must be able to deploy or control a contract that can issue an indirect built-in call; accounts without stored permissions and the native transaction path are not affected. Exploitation requires no user interaction, and no public exploit code or confirmed active exploitation was identified at time of analysis; this is nevertheless a genuine high-priority vulnerability given its unauthenticated-from-the-victim's-perspective account takeover impact on a production blockchain.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Missing BLS public key validation in Klever-Go prior to 1.7.20 allows a remote authenticated party with validator-registration capability (PR:L) to submit a CreateValidatorContract (Register) or ValidatorConfig update (UpdateValidator) containing a malformed BLSPublicKey that the runtime never checks for curve membership, prime-order subgroup, or nonzero value. Impact is delayed and conditional: the malformed-key validator must first become eligible and then be selected into a consensus group, at which point MultiSigner.Reset and the signature-verification creation path fail to deserialize the group key and cancel the slot, causing repeated missed consensus rounds and throughput degradation; a complete halt occurs only when the consensus group equals the eligible validator set. This is an availability-only, conditional risk - no public exploit identified at time of analysis, no KEV listing, and genesis-path validation is unaffected because it already calls CheckPublicKeyValid.
Improper enforcement of the marketplace settlement workflow in Klever-Go prior to 1.7.20 lets an authenticated seller settle a resting-bid NFT auction through the Claim seller-accept branch while leaving the claimed order loadable with a future EndTime and stale CurrentBid/CurrentBidder values. A later bidder can then submit a higher bid, be debited, and trigger a refund to the previous bidder even though the NFT has already been delivered, while Claim and CancelOrder both reject that bidder because IsClaimed is true - leaving them unable to obtain the NFT or recover their funds. The flaw is purely an integrity/business-logic issue (CWE-841, assessed CVSS:3.1 7.1, AV:N/AC:L/PR:L/UI:N with no confidentiality or availability impact, matching the vendor's 7.1 CVSS 4.0 rating); no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor fix is available in 1.7.20.
Integer overflow in Klever-Go's semi-fungible token (SFT) add-quantity path prior to version 1.7.19 allows a mint-role holder to bypass a finite per-nonce MaxSupply constraint, minting approximately 9.2×10^18 tokens in a single transaction. The SFTAddCirculation function in core/kapp/systemAccount/systemAcount.go increments Circulation before checking the cap, enabling an int64 wraparound that makes the MaxSupply comparison permanently false. A proof-of-concept unit test is included in GHSA-mrpp-v6pg-p54x confirming the bypass; no CISA KEV listing is present at time of analysis.
Unbounded goroutine exhaustion in Klever-Go versions 1.7.14-1.7.17 allows any connected libp2p peer to remotely degrade or deny service to a Klever blockchain node by flooding it with well-formed direct messages. The root defect is architectural: `directMessageHandler` in `network/p2p/libp2p/netMessenger.go` spawns an unrestricted goroutine per incoming message before the processor-level antiflood layer can reject it, meaning admission control is structurally bypassed at ingress. No public exploit code has been identified at time of analysis, though the GHSA advisory provides a precise code walkthrough that substantially lowers exploitation complexity. The fix is available in v1.7.18.
Unauthenticated remote crash in Klever-Go versions 1.7.14-1.7.17 allows any network peer to terminate a node process by gossiping a 3-byte protobuf Transaction with the RawData sub-message omitted, triggering a nil-pointer dereference in the synchronous P2P validation callback with no panic recovery. No account, stake, validator key, or funds are required - the attacker only needs network reachability to the libp2p gossip port. Repeated delivery targeting enough BLS validators can halt block production entirely, constituting a chain-halt attack against the Klever network. No public exploit code or CISA KEV listing was identified, but the trivial payload and zero-prerequisite nature of exploitation make this a high-urgency upgrade target.
Consensus quorum bypass in Klever-Go prior to v1.7.20 allows a low-privileged block producer to satisfy the two-thirds validator signature threshold using phantom padding bits in the PubKeysBitmap rather than genuine validator signatures. Because the BLS aggregate-signature check ignores bits beyond the consensus group size while the quorum counter does not, a crafted block header with set padding bits appears validly signed without a real supermajority, undermining blockchain finality and consensus safety. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 1.7.20.
Account takeover in Klever-Go's KleverUpdateAccountPermission built-in (all versions prior to 1.7.20) allows an attacker-controlled smart contract to replace a victim account's entire permission set without any victim key or signature. The handler authorizes updates using the attacker-supplied vmInput.RecipientAddr instead of the authenticated vmInput.CallerAddr, and because the default self-signer created by createDefaultOwnerPermission satisfies the contractHasValidPermission check, a contract can name any permissioned victim as recipient and install attacker-supplied Owner permissions - enabling asset theft or permanent lockout of the victim. The CVSS 4.0 score is 8.7 with a low-privilege vector (PR:L), reflecting that the attacker must be able to deploy or control a contract that can issue an indirect built-in call; accounts without stored permissions and the native transaction path are not affected. Exploitation requires no user interaction, and no public exploit code or confirmed active exploitation was identified at time of analysis; this is nevertheless a genuine high-priority vulnerability given its unauthenticated-from-the-victim's-perspective account takeover impact on a production blockchain.
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk request bodies without JSON escaping, allowing an attacker who can submit a SetAccountName transaction to inject forged bulk actions that create, overwrite, or delete documents in any index the indexer can write to. Because the name is stored in consensus account state, the poisoned value is replayed by new and historical indexers, and no access to the indexing host or the Elasticsearch port is required. Severity is rated 8.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:L; our independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H), exploitation requires an authenticated low-privilege on-chain account plus a deployment that actually runs the Elasticsearch indexer, and the issue is fixed in 1.7.20; no public exploit identified at time of analysis, though the upstream fix ships a regression test that reproduces the advisory's injection construction.
Missing BLS public key validation in Klever-Go prior to 1.7.20 allows a remote authenticated party with validator-registration capability (PR:L) to submit a CreateValidatorContract (Register) or ValidatorConfig update (UpdateValidator) containing a malformed BLSPublicKey that the runtime never checks for curve membership, prime-order subgroup, or nonzero value. Impact is delayed and conditional: the malformed-key validator must first become eligible and then be selected into a consensus group, at which point MultiSigner.Reset and the signature-verification creation path fail to deserialize the group key and cancel the slot, causing repeated missed consensus rounds and throughput degradation; a complete halt occurs only when the consensus group equals the eligible validator set. This is an availability-only, conditional risk - no public exploit identified at time of analysis, no KEV listing, and genesis-path validation is unaffected because it already calls CheckPublicKeyValid.
Improper enforcement of the marketplace settlement workflow in Klever-Go prior to 1.7.20 lets an authenticated seller settle a resting-bid NFT auction through the Claim seller-accept branch while leaving the claimed order loadable with a future EndTime and stale CurrentBid/CurrentBidder values. A later bidder can then submit a higher bid, be debited, and trigger a refund to the previous bidder even though the NFT has already been delivered, while Claim and CancelOrder both reject that bidder because IsClaimed is true - leaving them unable to obtain the NFT or recover their funds. The flaw is purely an integrity/business-logic issue (CWE-841, assessed CVSS:3.1 7.1, AV:N/AC:L/PR:L/UI:N with no confidentiality or availability impact, matching the vendor's 7.1 CVSS 4.0 rating); no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor fix is available in 1.7.20.
Integer overflow in Klever-Go's semi-fungible token (SFT) add-quantity path prior to version 1.7.19 allows a mint-role holder to bypass a finite per-nonce MaxSupply constraint, minting approximately 9.2×10^18 tokens in a single transaction. The SFTAddCirculation function in core/kapp/systemAccount/systemAcount.go increments Circulation before checking the cap, enabling an int64 wraparound that makes the MaxSupply comparison permanently false. A proof-of-concept unit test is included in GHSA-mrpp-v6pg-p54x confirming the bypass; no CISA KEV listing is present at time of analysis.
Unbounded goroutine exhaustion in Klever-Go versions 1.7.14-1.7.17 allows any connected libp2p peer to remotely degrade or deny service to a Klever blockchain node by flooding it with well-formed direct messages. The root defect is architectural: `directMessageHandler` in `network/p2p/libp2p/netMessenger.go` spawns an unrestricted goroutine per incoming message before the processor-level antiflood layer can reject it, meaning admission control is structurally bypassed at ingress. No public exploit code has been identified at time of analysis, though the GHSA advisory provides a precise code walkthrough that substantially lowers exploitation complexity. The fix is available in v1.7.18.
Unauthenticated remote crash in Klever-Go versions 1.7.14-1.7.17 allows any network peer to terminate a node process by gossiping a 3-byte protobuf Transaction with the RawData sub-message omitted, triggering a nil-pointer dereference in the synchronous P2P validation callback with no panic recovery. No account, stake, validator key, or funds are required - the attacker only needs network reachability to the libp2p gossip port. Repeated delivery targeting enough BLS validators can halt block production entirely, constituting a chain-halt attack against the Klever network. No public exploit code or CISA KEV listing was identified, but the trivial payload and zero-prerequisite nature of exploitation make this a high-urgency upgrade target.
Consensus quorum bypass in Klever-Go prior to v1.7.20 allows a low-privileged block producer to satisfy the two-thirds validator signature threshold using phantom padding bits in the PubKeysBitmap rather than genuine validator signatures. Because the BLS aggregate-signature check ignores bits beyond the consensus group size while the quorum counter does not, a crafted block header with set padding bits appears validly signed without a real supermajority, undermining blockchain finality and consensus safety. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 1.7.20.