CVE-2026-104891 in mppx-condition-gate
Summary
by MITRE • 10/05/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in the mppx-condition-gate package prior to version 3.0.0, alongside related issues in @insumermodel/mppx-token-gate before version 1.0.4, represents a critical authentication bypass within a payment verification system. This flaw stems from an insecure implementation of conditional access logic that governs free-access entitlements for specific cryptocurrency wallets. The core technical failure lies in the package's handling of client-supplied credentials, specifically the source field containing a wallet address. When processing these requests, the software retrieves the public address provided by the user and evaluates it against configured on-chain conditions designed to determine eligibility for free access. However, the implementation fails to verify that the entity making the request actually possesses control over the private keys associated with that public address. This omission allows any unauthenticated actor to arbitrarily select a wallet address that meets the predefined criteria and claim free access without ever proving ownership or signing a cryptographic message.
From an operational perspective, this vulnerability enables significant financial fraud and service abuse. An attacker can exploit this flaw by simply naming any qualifying wallet in their request parameters. Since the system does not invoke the wrapped payment verifier to confirm transactional integrity nor require proof of control such as digital signatures, the server blindly accepts the claim of eligibility. Consequently, attackers can obtain content or services that are strictly intended for paying customers at no cost. Furthermore, the presence of caching mechanisms exacerbates the impact by allowing these fraudulent free-access grants to be reused throughout their configured cache lifetime. This means a single successful exploitation attempt could potentially grant unauthorized access multiple times without requiring additional network interaction, amplifying the scale and duration of the abuse beyond immediate request handling.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to adequately verify the identity or authority of the user attempting to gain access. Additionally, it relates to CWE-345, Insufficient Verification of Data Authenticity, because the application trusts client-supplied data regarding wallet ownership without cryptographic validation. In terms of offensive security frameworks, this behavior mirrors techniques found in MITRE ATT&CK under privilege escalation or unauthorized resource consumption vectors where an attacker bypasses access controls by manipulating input parameters to satisfy logical conditions without fulfilling underlying authentication requirements. The lack of proof-of-control is a fundamental breach of secure design principles for blockchain-integrated applications, where ownership must be cryptographically proven rather than merely asserted via public address submission.
To mitigate this vulnerability and prevent similar issues in future implementations, developers must ensure that any system granting access based on wallet identity requires cryptographic proof of control. This typically involves implementing challenge-response mechanisms where the user signs a nonce or specific message with their private key, which is then verified against the submitted public address before free-access privileges are granted. The packages insumermodel/mppx-condition-gate and insumermodel/mppx-token-gate have been updated in versions 3.0.0 and 1.0.4 respectively to enforce this verification step, ensuring that authorization is only issued after payer control has been established through valid cryptographic signatures. Organizations relying on these libraries should immediately upgrade to the patched versions to close this authentication bypass gap and restore the integrity of their payment gating logic.