Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Location: core/kapp/validators/validators.go:201 (Register), (genesis/checking/nodesSetupChecker.go:73). core/consensus/slot/bls/subslotStartSlot.go:165 core/consensus/.../headerSignatureVerify.go:123 (Create(...)). Description Klever uses a BDN (Boneh-Drijvers-Neven) BLS multi-signature over BLS12-381 to finalize blocks (crypto/signing/mcl/multisig/bls.go, herumi/bls-go-binary). The library is initialized with only bls.Init(bls.BLS12381) and no order-verification flags, so Deserialize does not enforce prime-order-subgroup membership subgroup safety relies on explicit IsValidOrder() calls in the wrappers. Runtime validator registration (validators.Register) stores the submitted 96-byte BLSPublicKey via SetBLSPublicKey with no curve check, no subgroup check, and no proof-of-possession (CreateValidatorContract carries the key but no signature proving key ownership; grep confirms no proofOfPossession/VerifyProof/BLSSignature verification anywhere in core/kapp/validators/).…
Recommended action: Upgrade to 1.7.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Component: Elasticsearch indexer (indexer/) Primary location: indexer/common.go:2395-2407 (serializedDataForUpdateAccounts) Entry point: SetAccountName native transaction (contract type 12) — core/process/transaction/txProcess.go:688 --- Description When the node indexes account updates to Elasticsearch, it builds the ES bulk painless-script line by splicing the account's name directly into JSON with fmt.Sprintf("%s", ...) and no escaping: acc.Name originates from on-chain account state: indexer/accountInfo.go:31 sets Name: string(userAccount.GetName()). An account name is fully attacker-controlled and only weakly validated when it is set on-chain by the SetAccountName handler: The only constraints are valid UTF-8 and length ≤ 100 bytes. Double-quote ("), backslash (\), and newline (\n) are all valid UTF-8 and are not rejected. The safe helper converters.JsonEscape() exists and is used for id fields elsewhere in the same file (common.go:893, :932, :961) but is not applied to the…
Recommended action: Upgrade to 1.7.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Location: core/kapp/market/market.go — Buy() (approx. L281–436)\ Severity: High The native marketplace enforces an IsClaimed guard in Claim (market.go:752), CancelOrder (market.go:1125), and orderEscrowAmount (market.go:251), but not in Buy. Marketplace escrow is virtual: the market KApp account never custodies currency. A bid burns funds from the bidder (bidderAcc.SubFromBalance, ~L378), and refunds/payouts mint to the recipient (AddToBalance, e.g. the prior-bidder refund at ~L349). Soundness depends on each order's CurrentBid being paid out exactly once. A seller can settle a resting-bid auction early via the seller-accept branch of Claim (~L776) → executeBuyMarket (~L656). That path sets IsClaimed=true, delivers the NFT, pays the seller, and re-saves the order (SetMarketOrder, ~L726) — but, unlike every other settle path, it does not reset EndTime (contrast immediate-buy Buy ~L416 and CancelOrder ~L1206), and no code path deletes the order. The result is a "zombie" order: already…
Recommended action: Upgrade to 1.7.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The VM built-in function KleverUpdateAccountPermission (registered always-active, creator.go:381-390 / core/vmconstants.go:234) rewrites an account's entire permission set. Its authorization check uses vmInput.RecipientAddr attacker-controlled instead of the authenticated vmInput.CallerAddr. The sibling handler kleverChangeOwnerAddress.go:86 uses vmInput.CallerAddr correctly, so the safe pattern exists in-repo; this handler deviates. The native transaction path (txProcess.go:833) is safe it uses tx.GetSender(). Mechanism: 1. Wrong variable: CallerAddr is never referenced in the handler; auth is contractHasValidPermission(target.GetPermissions(), RecipientAddr), which returns true if RecipientAddr is a signer with Weight = Threshold in the target account's permissions and the permission grants UpdateAccountPermissionContractType. 2. RecipientAddr is attacker-controlled: when a contract calls a built-in via ExecuteOnDestContextWithTypedArgs (baseOps.go:1967),…
Recommended action: Upgrade to 1.7.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The unauthenticated WebSocket endpoint GET /subscribe is registered open: true by default (config/node/api.yaml) and lets a remote, unauthenticated client exhaust the node's memory and goroutines. Because the REST API runs IN-PROCESS with the node — network/api/api.go Start(...) ends with ws.Run(kleverFacade.RestAPIInterface()) — exhausting/killing the API process takes down the entire node, including its P2P and consensus participation. No API key, account, stake, or funds are required. Three compounding, independently-exploitable gaps stack on this one endpoint: 1. Permissive origin — upgrader.CheckOrigin always returns true (network/api/websocket/routes.go), so any web origin can complete the handshake. 2. No read-size limit — the connection never calls conn.SetReadLimit(...). gorilla's default is UNLIMITED, so a single conn.ReadJSON (processSubscription) or conn.ReadMessage (client.loopIn) can be forced to allocate an arbitrarily large buffer from ONE frame. 3. No…
Recommended action: Upgrade to 1.7.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated client can connect to GET /log, send an arbitrary logger profile as the first WebSocket message, and mutate the node's global logging configuration before receiving live logs from the process. I confirmed this against a local validator built from this repository: an unauthenticated client set the global log level to :NONE, the node accepted the profile, and the node stopped emitting normal slot logs while the WebSocket connection remained open. This is not a duplicate of the published KVM or P2P advisories. It is a management-plane flaw in the public WebSocket logging endpoint. Vulnerability details Affected code - Route exposed by default in config/node/api.yaml - Route registration in network/api/api.go - Unauthenticated upgrade in network/api/api.go - First client message is parsed as a logger profile and applied globally in network/api/logs/logSender.go - Global logger mutation happens in dependency github.com/klever-io/klever-go-logger, profile.go, Apply()…
Recommended action: Upgrade to 1.7.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On the SFT add-quantity path the only supply bound is SFTAddCirculation, which does meta.Circulation += amount with no overflow guard, then checks if meta.Circulation meta.MaxSupply && meta.MaxSupply != 0. If amount overflows int64 and wraps negative, negative MaxSupply is false, the cap check passes, the function returns nil, and the balance credit stands. A nonce created with a finite MaxSupply (e.g. 1000) can thus be minted to ~MaxInt64 tokens in one transaction. The fungible mint path is not vulnerable — it has a post-increment MintedValue <= 0 guard that the SFT path lacks. Affected code - core/kapp/systemAccount/systemAcount.go:132-138 (SFTAddCirculation, the unguarded +=). - Caller: core/kapp/kda/mint.go:247-283 (processSemiFungibleAddQuantity); contrast guard mint.go:289. Impact A mint-role holder mints ~9.2e18 units of a nonce whose declared MaxSupply is small, with no authorized debit, and corrupts the on-chain Circulation counter to a negative value (misleading any…
Recommended action: Upgrade to 1.7.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In processPercentageRoyaltiesTransfer the royalty pool is collected from the sender by SubFromBalance that is ordered after the split loop and after if royaltiesToPay <= 0 { return Ok }. The split-payout guard rejects only an allocation that exceeds the pool (a strict splitToPay royaltiesToPay), so a split entry of exactly 100% (PercentTransferPercentage = 10000) is a valid config: it drives royaltiesToPay to 0 and hits the early-return before the sender is debited. The split recipient keeps the full royalty; the sender pays nothing for it → mint. The sibling fixed-royalty path (processFixedRoyaltiesTransfer) debits the sender first and is safe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after the early-return. Affected code - core/kapp/accounts/accounts.go — processPercentageRoyaltiesTransfer: split loop → if royaltiesToPay <= 0 { return Ok } → acntSrc.SubFromBalance(royaltyAmount) (debit after the early-return).…
Recommended action: Upgrade to 1.7.19-rc4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The per-entry percentages of a KDA asset's split royalties are validated by summing them into a uint32 accumulator and checking the sum against HundredPercent (10000), with no upper bound on each individual entry. Two split entries whose percentages sum to just over 2^32 wrap around below 10000 and pass validation, while each stored value remains astronomically large (e.g. 0x80000000 = 2,147,483,648 ≈ 21,474,836%). At royalty payout, each split recipient is credited pool × hugePct / 10000 — far more than the royalty pool — and the resulting negative remainder is silently discarded (if royaltiesToPay <= 0 { return Ok }). Because fixed royalties (and marketplace/ITO royalties) are denominated in KLV, an attacker mints KLV (the native token) out of thin air, on demand, by transferring or selling their own throwaway asset. This is independent of, and not mitigated by, the existing FixMarketBuyOverflow guard. Affected component - Repository: klever-io/klever-go (node). -…
Recommended action: Upgrade to 1.7.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a marketplace order is settled (MarketBuy / BuyItNow, and auction Claim), the buyer's payment is split three ways — referral, royalties, and the seller (market-order owner) remainder: Referral and royalties are paid out unconditionally, but the seller remainder is only paid when positive (computeMarketOwnerAmount returns Ok and pays nothing when the amount is <= 0). When referral% + royalty% exceeds 100% of the bid, marketOwnerAmount goes negative and is silently skipped — so the marketplace pays out more KLV / sale currency than the buyer paid in, minting the difference out of thin air. The combined ceiling royalty% + referral% <= 100% is checked once, at listing time (Sell). But the two percentages are sourced asymmetrically at settlement: - referral % is snapshotted into the order at Sell (MarketOrderData.ReferralPercentage); - royalty % is never snapshotted — it is read live from the asset at buy time (asset.Royalties.MarketPercentage). So the listing-time invariant…
Recommended action: Upgrade to 1.7.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/klever-io/klever-go >= 1.7.14, <= 1.7.17
Fixed in
1.7.18· Vendor fix available
Issue
Every transaction gossiped on the klever-go P2P network is decoded and validated synchronously inside the libp2p pubsub topic-validator callback. The validator txVersionChecker.CheckTxVersion dereferences tx.RawData.Version with no nil check. A protobuf Transaction whose embedded RawData sub-message is omitted decodes to RawData == nil, so validating it triggers a nil-pointer panic. The libp2p pubsub callback, the underlying go-libp2p-pubsub validation worker, and klever's own network/p2p layer install no recover(), so the panic propagates and crashes the entire node process. The attacker payload is a 3-byte protobuf message; no validator key, stake, funds, or on-chain account is required. Aimed at enough of the BLS validator set, repeated delivery halts block production (chain halt). Affected component - Root cause: core/versioning/txVersionChecker.go:22 - Reached via: core/process/transaction/interceptedTransaction.go:203 (integrity) and :154 (CheckValidity) - Production…
Recommended action: Upgrade to 1.7.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/klever-io/klever-go >= 1.7.14, <= 1.7.17
Fixed in
1.7.18· Vendor fix available
Issue
The Klever seednode REST API starts a Gin engine with Engine.Run(restAPIInterface). In Gin v1.9.1, Engine.Run calls Go's default http.ListenAndServe, which constructs an HTTP server without application-level ReadHeaderTimeout, ReadTimeout, or MaxHeaderBytes limits. An unauthenticated client that can reach a REST listener bound with Klever's documented --rest-api-interface :8080 all-interface option can hold incomplete HTTP headers open indefinitely. In a local proof against the real cmd/seednode/api.Start path on v1.7.17, 120 slow-header connections caused 20/20 legitimate /log probes to fail with accept: too many open files. A fixed control using the same Gin router behind an explicit http.Server with ReadHeaderTimeout, ReadTimeout, and MaxHeaderBytes retained 0 slow connections and served 20/20 probes. This report is distinct from the P2P advisories and from my direct-message goroutine report. This finding concerns Klever-owned HTTP REST startup code (cmd/seednode/api and…
Recommended action: Upgrade to 1.7.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/klever-io/klever-go >= 1.7.14, <= 1.7.17
Fixed in
1.7.18· Vendor fix available
Issue
networkMessenger.directMessageHandler in network/p2p/libp2p/netMessenger.go spawns a fresh goroutine for every incoming direct message before the antiflood layer makes an admission decision. There is no semaphore, throttler, or bound on concurrent in-flight spawns. A single connected libp2p peer can open a DirectSendID stream and send well-formed TopicMessage envelopes with varying sequence numbers. Each accepted direct message reaches directMessageHandler and triggers a fresh goroutine before processor.ProcessReceivedMessage runs. This allows unbounded goroutine growth and node availability degradation from one peer. This remains present in the latest release v1.7.17: network/p2p/libp2p/netMessenger.go:1060 still spawns go func(msg p2p.MessageP2P) before processor.ProcessReceivedMessage. I also verified current develop commit 10bcfd50, where the same spawn remains at network/p2p/libp2p/netMessenger.go:1115. This is distinct from GHSA-74m6-4hjp-7226 and GHSA-87m7-qffr-542v.…
Recommended action: Upgrade to 1.7.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The account-data trie syncers leak bounded throttler slots on error paths in syncDataTrie(). Each failed trie sync permanently consumes one slot from the NumGoRoutinesThrottler, and the slot is never returned unless the sync succeeds or the root hash was already present. I confirmed this on the current default branch develop at commit 9640d63 (observed on May 20, 2026). I also confirmed the bug with a runtime PoC using the real timeout path in trieSyncer.StartSyncing(): two timed-out sync attempts are enough to exhaust a throttler with capacity 2. This affects the epoch bootstrap path because syncUserAccountsState() and syncKappAccountsState() create bounded throttlers and abort bootstrap immediately if the syncer returns an error. Once enough trie-root sync attempts fail, the syncer cannot make forward progress and bootstrap fails. Affected Components - data/syncer/userAccountsSyncer.go - data/syncer/kappAccountsSyncer.go - data/trie/sync.go -…
Recommended action: Upgrade to 1.7.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A connected peer can send a compressed RequestDataTypeHashArrayType direct request that is only 442 bytes on the wire but expands into 200000 decoded hash entries inside the resolver path. On klever-go v1.7.17, this allows remote memory and CPU amplification against nodes that accept P2P peer connections. Details Resolver antiflood logic accounts only one logical message and the compressed wire size in data/retriever/resolvers/messageProcessor.go#L30. Batch.Decompress() in data/batch/batch.go#L122 enforces an inflated byte cap but does not enforce a decoded repeated-field item cap. After decompression, TxResolver preallocates and iterates all decoded hashes in data/retriever/resolvers/transactionResolver.go#L194, and TrieNodeResolver iterates the same unchecked decoded set in data/retriever/resolvers/trieNodeResolver.go#L108. Pinned references: -…
Recommended action: Upgrade to 1.7.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Publisher note Fixed in v1.7.17. Operators running < v1.7.17 should upgrade. The decompression-error path in MultiDataInterceptor.ProcessReceivedMessage now releases the global throttler slot before returning (guarded defer after StartProcessing(), disabled when the asynchronous goroutine takes ownership). Patch commits on develop: 333f6ec9, 68b94a40 (merged from private fork klever-io/klever-go-ghsa-74m6-4hjp-7226). This advisory was originally filed jointly with a separate KVM read-only isolation bypass; that finding is now tracked under GHSA-jc6w-wmfc-fh33 so each issue receives its own CVE. The original disclosure from @LoGGGG240211 follows verbatim, including the embedded proof-of-concept source. --- Private Vulnerability Report Repository: klever-io/klever-go Reviewed commit: 405d01b0abbf0d3e73b4a990bd7394a01f200dc2 Disclosure channel: GitHub Private Vulnerability Reporting Reporter GitHub account: LoGGGG240211 2.1 MultiDataInterceptor malformed compressed batches permanently…
Recommended action: Upgrade to 1.7.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Publisher note Fixed in v1.7.17. Operators running < v1.7.17 should upgrade. Contract delete and upgrade host-core paths now reject execution when runtime.ReadOnly() is true. The invariant is regression-tested for delete, upgrade, storage writes, value transfers, and any VM output field that can later mutate chain state. Patch commits on develop: 333f6ec9, 68b94a40 (merged from private fork associated with the original advisory). This advisory was originally filed jointly with a separate P2P throttler DoS finding, now tracked under GHSA-74m6-4hjp-7226 so each issue receives its own CVE. The original disclosure from @LoGGGG240211 follows verbatim, including the embedded proof-of-concept source. --- Private Vulnerability Report Repository: klever-io/klever-go Reviewed commit: 405d01b0abbf0d3e73b4a990bd7394a01f200dc2 Disclosure channel: GitHub Private Vulnerability Reporting Reporter GitHub account: LoGGGG240211 2.2 KVM read-only execution can commit contract delete side effects…
Recommended action: Upgrade to 1.7.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.