Description

mppx-condition-gate provides conditional free-access wrappers for mppx payment methods. Prior to @insumermodel/mppx-condition-gate 3.0.0 and @insumermodel/mppx-token-gate 1.0.4, the packages read a wallet address from the client-supplied credential.source, checked whether that public address met configured on-chain conditions, and returned a successful free-access receipt without invoking the wrapped payment verifier or proving that the caller controlled the wallet. An unauthenticated attacker could name any qualifying wallet and obtain content that should require payment, and cached grants could be reused for the configured cache lifetime. The corrected packages prevent free-access authorization unless payer control has been established. These issues are fixed in @insumermodel/mppx-condition-gate 3.0.0 and @insumermodel/mppx-token-gate 1.0.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-05T16:17:06.447Z",
  "pubdate": "2026-10-05T16:17:06.447Z",
  "executiveSummary": "The vulnerability involves an improper authorization mechanism within @insumermodel/mppx-condition-gate and @insumermodel/mppx-token-gate. It is categorized as a failure to establish proof of ownership for supplied cryptographic credentials.\nThe core flaw allows unauthenticated attackers to bypass payment requirements by spoofing arbitrary wallet addresses that satisfy on-chain conditions.\nThis impacts access control integrity, permitting unauthorized users to obtain restricted content or services intended for paying users only.\nThe risk is high, as the vulnerability is remotely exploitable without authentication, requiring only knowledge of a qualifying public wallet address to gain illicit access.\nThe issue persists because the system relies on client-provided input for validation without verifying that the caller possesses the private keys associated with the provided wallet address.\nThe exploit bypasses the intended payment verification logic entirely, leading to direct access to protected assets.",
  "technicalDetails": "The vulnerability resides in the way @insumermodel/mppx-condition-gate and @insumermodel/mppx-token-gate process client-supplied data. Specifically, the packages extract the wallet address directly from the 'credential.source' object provided by the client.\nThe root cause is a lack of cryptographic proof-of-possession (e.g., a signature validation) for the address being processed. The authorization logic executes a check to see if the supplied public address meets on-chain conditions (such as holding specific tokens or meeting eligibility criteria), but it fails to verify that the request originator actually owns or controls the corresponding private key for that address.\nThe attack flow follows these steps: 1. An attacker identifies a target on-chain condition required for access. 2. The attacker selects a public wallet address that satisfies this condition. 3. The attacker crafts a request to the application, setting 'credential.source' to the target wallet address. 4. The server-side logic processes the input, validates that the chosen address meets the on-chain condition, and immediately returns a successful 'free-access' receipt.\nCrucially, the wrapped payment verifier is never invoked, and no cryptographic challenge-response sequence is performed. Because the system assumes that 'credential.source' implies legitimate access, the application grants the requested content. Furthermore, if the system implements a caching mechanism for these grants, the unauthorized access persists for the duration of the configured cache lifetime, allowing the attacker to continue accessing protected resources without subsequent validation.\nAffected versions include @insumermodel/mppx-condition-gate prior to version 3.0.0 and @insumermodel/mppx-token-gate prior to version 1.0.4. The exploitation requires no specific privileges and is entirely unauthenticated, as the application logic itself treats the initial unverified request as a valid authorization event.\nPost-exploitation, the attacker gains full access to paid/gated content. By rotating public addresses that meet specific on-chain criteria, an attacker can maintain continuous, unauthorized access to system resources that are supposed to be protected by payment or wallet-gating mechanisms."
}