Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated remote client to obtain paid resources by resubmitting one settled on-chain transfer.
MPP.Methods.EVM.verify/2 accepts a transaction-hash credential and matches a transfer purely on token, to and amount (ERC-20) or to and value (native). It binds the proof neither to the challenge being verified nor to any record of prior use, and the generic MPP.Plug dedup store keys on challenge.id, which is regenerated for every 402 response. On a static-price route, a single historical transfer matching the charge therefore satisfies an unbounded number of later charges, including transfers an attacker can read off a public block explorer.
This issue affects mpp: from 0.3.0 before 0.6.3.
Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.
MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (maxgas, maxfeepergas, maxpriorityfeepergas, the worst-case gaslimit maxfeepergas <= maxtotalfee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reservehashatomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times maxtotalfee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.
This issue affects mpp: from 0.2.0 before 0.12.0.
Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated third party to obtain paid resources by replaying a transfer settled by an unrelated payer.
MPP.Methods.Tempo normally binds a settled TIP-20 TransferWithMemo to the specific challenge under verification through an attribution nonce carried in the memo. When a static "memo" is configured in methodconfig, checkmatchedmemobinding/3 returns the match unconditionally and that binding is skipped, leaving only token, recipient, amount and the static memo value to match on. The static memo is echoed in every unauthenticated 402 response and Tempo transfers are public, so an attacker can take any matching transfer paid by a legitimate customer, request a fresh challenge for the same route, and present that transaction hash as a type="hash" credential. The hash path performs no sender or signature check tying the presenter to the wallet that broadcast the transfer.
This issue affects mpp: from 0.6.1 before 0.6.4.
Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients.
When the mpp Elixir library is configured as fee payer (feepayer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gaslimit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gaslimit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpcbroadcastsync. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests.
The waitforconfirmation = false (optimistic) path is also affected: it invokes simulatepaymentcall via ethcall, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions.
This issue affects mpp: from 0.2.0 before 0.6.0.