Threat Intelligence Database

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly. The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key. This issue affects mpp: from 0.14.0 before 0.16.2.

Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged. MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports. This issue affects mpp: from 0.14.0 before 0.16.2.

Improper Validation of Unsafe Equivalence in Input in ZenHive mpp allows an unauthenticated remote client to pass the Tempo duplicate-submission gate twice with one signed transaction. MPP.Methods.Tempo reserves the pre-broadcast dedup slot on the caller-supplied hex in reserve_hash_atomic/2, keyed through store_key/1 on tx.raw rather than on a canonical form of the transaction. The deserializer stores the caller's hex verbatim and accepts both recovery-id encodings, so one signed transaction submitted once with v=27 and once with v=0 yields two distinct reserve keys, and both pass the reserve and reach the broadcast path. The plug-level credential replay store is deliberately carved out for tempo in lib/mpp/replay.ex, leaving this reserve as the only gate, and the post-broadcast mark writes the canonical hash key that the raw-keyed reserve never reads. What the duplicate submission yields depends on the node: a nonce-reuse rejection fails closed, while a node that answers with the canonical hash for an already-known transaction returns a second valid Payment-Receipt for a single on-chain payment. This issue affects mpp: from 0.2.0 before 0.16.2.

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid. MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource. This issue affects mpp: from 0.1.0 before 0.16.2.

CVE-2026-82750 is a high-severity vulnerability in ZenHive mpp versions from 0.2.0 up to but not including 0.16.1. It involves improper validation of the specified quantity in input, allowing unauthenticated remote clients to inflate the gas cost paid by the fee-payer for sponsored payments. Specifically, the vulnerability arises because the server does not validate the aa_authorization_list field, enabling clients to attach multiple delegations that increase the gas cost significantly. This can lead to sponsors paying excessive gas fees and clients upgrading their accounts to delegated code at the sponsor's expense.

CVE-2026-82751 is a vulnerability in ZenHive mpp that allows an unauthenticated remote client to cause a sponsor to pay significantly increased gas fees by exploiting improper validation of input quantities. Specifically, the client can attach a signed key authorization to provision a new access key with token spending limits on their own account, which the sponsor pays for. This leads to inflated gas costs and unauthorized access key creation. The issue affects versions from 0.2.0 up to but not including 0.16.1.

CVE-2026-73136 is an authentication bypass vulnerability in ZenHive mpp versions 0.6.1 up to but not including 0.6.4. It allows an unauthenticated attacker to replay a previously settled transfer to obtain paid resources without authorization. The flaw arises because a static memo configuration disables proper binding of transfers to authentication challenges, enabling replay attacks using public transfer data.

A resource allocation flaw in ZenHive mpp versions from 0.2.0 before 0.12.0 allows unauthenticated remote clients to drain the fee-payer wallet by sending multiple concurrent sponsored payment transactions. The system enforces fee limits per transaction but does not account for cumulative exposure across concurrent requests, enabling denial of service once the wallet is depleted.

A Time-of-check Time-of-use (TOCTOU) race condition exists in ZenHive mpp that allows an unauthenticated remote client to redeem a single confirmed on-chain payment multiple times for paid-resource accesses. The vulnerability arises because the 'hash' credential verification path uses a non-atomic check-then-mark sequence, enabling concurrent requests with the same payment hash to bypass replay protection. This affects versions from 0.2.0 up to but not including 0.6.1. The default configuration does not provide replay protection, and exploitation requires a deduplication store to be configured.

CVE-2026-67581 is an authentication bypass vulnerability in ZenHive mpp versions from 0.3.0 before 0.6.3. It allows an unauthenticated remote attacker to reuse a previously settled on-chain transfer to obtain paid resources without authorization. The vulnerability arises because the verification method accepts a transaction hash credential and matches transfers based only on token, recipient, and amount, without binding the proof to the specific challenge or preventing reuse. This enables replay attacks using publicly visible blockchain transactions.