The Klever-Go project has published two critical advisories for flaws that could create unbacked KLV tokens. CVE-2026-54754 was used against the Klever mainnet in June, while CVE-2026-54755 describes a separate split-royalty overflow with no confirmed exploitation. Both issues are fixed in Klever-Go 1.7.19, so node operators should verify their version and the mainnet activation epoch rather than treating the new disclosures as a fresh wallet-key breach.
What the Klever advisories reveal
The two bugs break the same accounting rule in different places: a transaction must never pay recipients more value than the sender supplied. In both cases, Klever-Go could credit KLV balances without a matching debit and without recording a normal mint.
| Issue | Risk and fix |
|---|---|
| CVE-2026-54754 CVSS 9.6 |
A marketplace order could snapshot a valid referral percentage, then read a higher live royalty percentage at settlement. Referral and royalty recipients were paid, while a negative seller remainder was silently skipped. This path was exploited on mainnet. Klever-Go 1.7.19 rejects the transaction before any payout. |
| CVE-2026-54755 CVSS 9.6 |
Two oversized split-royalty percentages could overflow a 32-bit sum and pass validation. Later payouts could credit far more KLV than the royalty pool contained. Klever-Go 1.7.19 bounds the values and rejects payouts above the pool. No in-the-wild exploitation is reported. |
The CVE-2026-54754 advisory says an attacker could create a collection and marketplace, list an NFT with a valid combined cut, raise the live royalty after listing, and then buy from an account they also controlled. Settlement paid the referral and royalty shares in full but discarded the negative seller share, creating the difference as spendable KLV.[2]
Klever’s incident report places the observed exploit window between June 4 at 10:38 UTC and June 5 at 11:30 UTC. It attributes 283 transactions across four NFT collections and two marketplaces to the operation and reports 486,357,300.26 KLV artificially created before the emergency response.[1] That figure is the vendor’s incident estimate; it should not be confused with normal protocol minting or proof that every KLV holder lost funds.
The second flaw could bypass royalty limits
CVE-2026-54755 is independent of the marketplace timing bug. Klever-Go decoded each split percentage as an unsigned 32-bit value, added the values into another 32-bit accumulator, and checked only the wrapped sum. Two very large entries could therefore wrap the total below the 100% limit.
When a transfer, marketplace purchase, or initial token offering later distributed that royalty pool, each attacker-controlled recipient could be credited from the huge stored percentage. The code then treated a negative remainder as a successful no-op instead of rejecting the transaction. The advisory demonstrates the path on a local node but does not say it was used on mainnet.[3]
What node operators and KLV holders should do
- Run Klever-Go 1.7.19 or later. The official release says every node must use the network’s
fixMarketBuyOverflowactivation epoch. Mainnet activated the change at epoch 5741 on June 5 at 19:00 UTC. A mismatched epoch can make a node diverge from consensus.[4] - Review the June incident window. Validators, exchanges, and monitoring teams should retain marketplace and bridge evidence from June 4–5. Look for repeated self-trades, the same party controlling buyer, seller, referral, and royalty addresses, payout receipts exceeding the original bid, and collections or markets created shortly before the activity.
- Reconcile deposits and balances. Exchanges and services that handled KLV during the incident should compare transaction inputs, settlement receipts, bridge activity, and credited customer balances. A normal supply dashboard may not expose value credited directly to balances.
- Do not rotate or disclose a seed phrase because of these CVEs alone. These are protocol accounting flaws, not evidence that Klever wallet seeds or private keys were stolen. Use official Klever notices for service status. If a wallet balance or exchange deposit looks wrong, preserve transaction IDs and contact the relevant service without sharing the seed phrase.
For a separate example of why a cryptocurrency incident does not automatically mean a seed phrase was exposed, see our guide to the Ill Bloom wallet address vulnerability.
FAQ
Was the Klever Wallet hacked?
The disclosed bugs are in Klever-Go’s marketplace and royalty accounting. The sources do not establish theft of wallet seeds or private keys. The practical risks are unbacked token creation, economic impact, and incorrect balances around the incident.
Is CVE-2026-54754 still being exploited?
The vendor says the June incident was mitigated, and Klever-Go 1.7.19 contains the protocol fixes. The new advisories provide technical detail but do not claim a continuing campaign. Nodes below the fixed version remain the configuration that requires action.
References
- Klever. “Security Incident Report — Updated.” Klever Forum, June 6, 2026; accessed August 28, 2026. https://forum.klever.org/t/security-incident-report-updated/4450
- Klever-Go project. “Marketplace settlement mints KLV when referral and royalty percentages exceed the bid (CVE-2026-54754).” GitHub Security Advisory GHSA-p7gw-2pcp-5pf8, August 28, 2026. https://github.com/klever-io/klever-go/security/advisories/GHSA-p7gw-2pcp-5pf8
- Klever-Go project. “Integer overflow in split-royalty validation enables unbounded KLV minting (CVE-2026-54755).” GitHub Security Advisory GHSA-cgc5-v3f2-8m2v, August 28, 2026. https://github.com/klever-io/klever-go/security/advisories/GHSA-cgc5-v3f2-8m2v
- Klever-Go project. “v1.7.19 — Marketplace & SFT Mint Security Release.” GitHub, June 22, 2026. https://github.com/klever-io/klever-go/releases/tag/v1.7.19
