ZenHive mpp vulnerabilities

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 a vulnerability of allocation of resources without limits or throttling, allowing an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty. The fee policy enforces limits only per transaction, not across concurrent requests.

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.