External risk intelligence

Klever-Go Marketplace Settlement Allows Unbacked Currency Creation

CVE advisorySeverity: CRITICAL (CVSS 9.6)

CVE-2026-54754

The vulnerability exists in the marketplace settlement logic of a blockchain protocol implementation. While blockchain nodes or marketplace services may be exposed to the internet to facilitate transactions, the specific logic for asset royalties and order settlement typically runs within the backend protocol layer rather than being a direct, public-facing internet edge or gateway service.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This vulnerability in a blockchain protocol implementation could allow unauthorized currency creation or corruption of token supply integrity by manipulating marketplace settlement. It affects backend protocol layers and requires a low level of access to exploit, with potential for significant impact on the digital asset ecosystem.

Blockchain currency and supply integrity are at risk.
Leadership should remember potential for unbacked currency.
Confirm relevance and exposure within your blockchain operations.

Attack Path

How an attacker could exploit the issue

An attacker with some access could manipulate marketplace settlements to create unbacked currency and corrupt token supply. This is achieved by creating a listing with a specific referral percentage, then updating the asset's royalty percentage to exceed the bid. When a purchase occurs, the system unconditionally pays out both percentages, potentially crediting the buyer with more currency than they paid.

Requires authenticated access to list assets.
Triggered during marketplace purchase settlement.
Results in unbacked currency and supply corruption.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow for the creation of unbacked currency and corruption of the token supply within the Klever blockchain protocol. This occurs when a malicious actor manipulates referral and royalty percentages during marketplace settlements, leading to a discrepancy where more cryptocurrency is issued than was paid for in a transaction. The conditions for this to happen involve an asset owner who can create a listing and then update royalty settings to exceed the bid amount, with the settlement process then unconditionally paying out excess amounts.

Token supply integrity.
Marketplace settlement manipulation.
Unbacked currency creation.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts the marketplace settlement logic within the Klever blockchain protocol. The immediate priority is to identify all instances of the affected software, determine their business criticality and network exposure, and confirm the accountable ownership for remediation. Once identified, a risk-based remediation plan should be developed, which may involve coordination with vendors or planning for maintenance windows.

Ownership: Confirm accountable application or platform owners.
Verify: Assess exposure and business criticality first.
Action: Plan and execute targeted remediation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Klever-Go?

Klever-Go is the official Go-language implementation of the Klever blockchain protocol. It serves as the underlying software that nodes use to process transactions, manage assets, and execute the marketplace logic that powers the Klever ecosystem, such as handling buy orders, auctions, and royalty payments.

What is the vulnerability in CVE-2026-54754?

This issue involves a financial calculation flaw categorized as CWE-682 (Incorrect Calculation), alongside potential integer underflow (CWE-191) and race conditions (CWE-367). Essentially, the software fails to properly validate the sum of referral and royalty fees during a purchase. This allows the combined payout to exceed the total amount paid by the buyer, creating an imbalance that corrupts the token supply.

How is this marketplace flaw triggered?

An attacker triggers this by first creating a valid marketplace listing, then using an update function to change the asset's royalty percentage. When a purchase occurs, the system's settlement logic blindly pays out both the original referral fee and the updated royalty. Simple browsing or listing viewing does not trigger the bug; it requires the specific state change of an asset's royalty settings combined with a completed marketplace transaction.

Is my node at risk according to Halo Surface Signal?

Halo Surface Signal notes that while blockchain nodes often sit on the internet to function, this specific vulnerability resides deep within the backend protocol's marketplace settlement logic. It is not a direct gateway or edge service vulnerability, but it remains relevant for any infrastructure running Klever-Go that actively processes market transactions or settlement orders.

What should I do to secure my Klever-Go deployment?

The primary response is to upgrade to Klever-Go version 1.7.19 or later, which contains the fix for the settlement logic. Before patching, identify which of your nodes or backend services are actively handling marketplace operations and verify their current version. Prioritize these active settlement services for the update to ensure the integrity of your token transactions.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.