npm package report

Is @insumermodel/mppx-condition-gate safe?

1 known vulnerability, worst severity HIGH.

// reach

0 direct dependencies

none carry a known advisory

    0 packages depend on it

    an advisory here reaches each of them

      Create a free accountfor every dependency path, dependent and what to upgrade
      // ai model usage

      Tracked for PyPI packages. HuggingFace models declare Python dependencies, so npm packages are not covered.


      cvss
      0.0
      high

      severity out of 10

      epss
      0.00%
      low

      chance of exploitation in 30 days, 19th percentile of all CVEs

      xyz score
      not scored

      CyberXYZ composite out of 10

      fig. 01 — GHSA-jg6q-3qfh-r9f8, the advisory selected below

      // 1 advisories

      GHSA-jg6q-3qfh-r9f8

      HIGHCVE-2026-104891
      // impact

      Both packages wrap an mppx payment method so that a wallet meeting on-chain conditions is granted free access instead of being charged.

      The free-access path reads the payer address from credential.source — a client-supplied DID in the payment credential — asks InsumerAPI whether that address satisfies the configured conditions, and on a pass returns a successful receipt without ever calling the wrapped payment verifier. Nothing in that path establishes that the caller controls the wallet it named.

      Because qualifying wallets are public chain state, an attacker does not need to guess one. Naming any qualifying address in credential.source is sufficient to obtain free access to a route that should have been paid for. An in-process cache (default TTL 300s, keyed on wallet and conditions) then re-serves the grant without re-evaluating.

      mppx documents this requirement explicitly. Its type definitions describe source as "an asserted identity, not independent proof of control", and state that methods relying on it "must validate the relationship to the credential payload". These packages did not.

      This is a defect in these wrapper packages, not in the attestation they consume. The attestation answers one question — does this wallet satisfy these conditions — and answered it honestly about the address it was given. Binding that address to the caller was the wrapper's responsibility.

      // affected versions

      Every published version of both packages is affected. The vulnerable control flow is present from the first release of each.

      // patches

      Fixed releases will not grant free access unless the payer has been proven, and fall through to the paid path wherever no proven payer is available.

      // workarounds

      Remove the condition gate from the payment method until a fixed version is installed, so all requests take the normal paid path. Alternatively, ensure the wrapped payment method has already bound the credential to the payer before the gate is consulted.

      // credit

      Reported by @chenshj73, who identified the issue, traced the exact code path, and proposed correct remediations.

      // cvss v3.1 vector

      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

      Attack vector
      Network
      Attack complexity
      Low
      Privileges required
      None
      User interaction
      None
      Scope
      Unchanged
      Confidentiality
      High
      Integrity
      None
      Availability
      None

      Checked 2026-10-08 at 00:25 UTC. The most recent advisory here was published 2026-10-07. Updated continuously from NVD, GHSA, OSV and CNA feeds.

      Think a verdict here is wrong? Tell us — we respond within 2 business days.