CVE-2026-73541

ZenHive mpp (from 0.14.0 before 0.16.2) has improper validation of specified quantity in input. A client with an open payment channel can obtain paid resources without being charged because a voucher with the same cumulative amount is treated as an idempotent success and maybe_spend/2 is not called. The same signed voucher can be re-presented under new challenges, yielding an unbounded number of paid units.

ZenHive mpp (from 0.14.0 before 0.16.2) is vulnerable to authentication bypass by capture-replay. An attacker holding a captured subscription activation credential can repeatedly charge the payer because the signed authorization is not tied to the challenge and activation deduplication is keyed by challenge id. Each replay triggers a new first-period settlement and re-authorizes the server key.

Improper validation in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment and have the sponsor pay for provisioning an access key on the client's own account. Missing check of the key_authorization field in the 0x76 envelope allows attaching a signed key, increasing cost from about 46,587 to about 1,808,700 gas.

Improper validation in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment and have the sponsor pay for EIP-7702 account delegations of the client's choosing. Missing read of the aa_authorization_list field in the 0x76 envelope allows attaching delegations, increasing cost from about 46,575 to about 1,884,087 gas.

Time-of-check Time-of-use (TOCTOU) Race Condition in ZenHive mpp allows an unauthenticated remote client to redeem one confirmed on-chain payment for multiple paid-resource accesses. The type="hash" credential path in MPP.Methods.Tempo.verify/2 guards against replay with a non-atomic check-then-mark sequence: check_hash_unused/2 reads the dedup store, an eth_getTransactionReceipt round trip verifies the payment on chain, and only then does mark_hash_used/2 write the mark. Concurrent requests carrying the same settled payment hash all pass the read before any of them writes, so each is issued a receipt. The store's atomic check_and_mark/2 primitive is available and used by the type="transaction" path, but the hash path calls plain get and put even when the configured store implements it. Exploitation requires a dedup store to be configured; the default nil store is stateless and documented as offering no replay protection at all. This issue affects mpp: from 0.2.0 before 0.6.1.

ZenHive mpp is affected by an authentication bypass by capture-replay vulnerability, allowing an unauthenticated third party to obtain paid resources by replaying a transfer settled by an unrelated payer. When a static 'memo' is configured, the binding check is skipped, and an attacker can use a public transfer as a credential.

A vulnerability in ZenHive mpp allows an unauthenticated remote client to obtain paid resources by resubmitting one settled on-chain transfer. The EVM verification mechanism does not bind the proof to the challenge or prior use, and deduplication keys are regenerated on every 402 response. On a static-price route, a single historical transfer satisfies an unbounded number of later charges.