E.Fu

**Name of the Vulnerable Software and Affected Versions** ZenHive mpp versions 0.2.0 through 0.16.0 **Description** Improper validation of input quantities allows an unauthenticated remote client to significantly increase the gas cost for a fee-payer during sponsored payments. The issue occurs when the server sponsors Tempo payments via the `MPP.Methods.Tempo.FeePayerPolicy.measure/3` function in `lib/mpp/methods/tempo/fee payer policy.ex`. While the function bounds gas fields, fee budget, validity window, and the access list of the client-signed 0x76 envelope, it fails to read the `aa authorization list` field. Consequently, a client can attach delegations from throwaway authority keys, forcing the sponsor to pay the intrinsic gas for these delegations within the default `gas limit` ceiling. This can result in costs increasing from approximately 46,575 gas to 1,884,087 gas. Additionally, since each entry is applied as a persistent set-code delegation, a client can upgrade its own accounts to delegated code at the sponsor's expense. **Recommendations** Update ZenHive mpp to version 0.16.1 or later. Disable Tempo fee sponsorship by setting `fee payer` to false and removing the `fee payer url` so the client pays its own gas. Lower the `max gas` override in `fee payer policy` to a value slightly above a legitimate sponsored payment (approximately 50,000 gas for a TIP-20 transfer) to bound the potential gas inflation.

**Name of the Vulnerable Software and Affected Versions** ZenHive mpp versions 0.2.0 through 0.16.0 **Description** Improper validation of input quantities allows an unauthenticated remote client to significantly increase the gas cost for a sponsor during sponsored payments. The issue occurs when the server sponsors Tempo payments via the `MPP.Methods.Tempo.FeePayerPolicy.measure/3` function in `lib/mpp/methods/tempo/fee payer policy.ex`. While the function bounds gas fields, fee budgets, validity windows, and access lists of the client-signed 0x76 envelope, it fails to check for the optional `key authorization` field. An attacker can attach a signed key authorization to a payment call to provision a new access key with token spending limits on their own account. These operations are billed as intrinsic gas to the sponsor, potentially increasing the cost from approximately 46,587 gas to 1,808,700 gas per payment. **Recommendations** Update ZenHive mpp to version 0.16.1 or later. Disable Tempo fee sponsorship by setting `fee payer` to false and removing the `fee payer url` so clients pay their own gas. Lower the `max gas` override in `fee payer policy` to a value slightly above a legitimate sponsored payment (approximately 50,000 gas for a TIP-20 transfer) to limit the potential gas inflation.

**Name of the Vulnerable Software and Affected Versions** ZenHive mpp versions 0.6.1 through 0.6.3 **Description** An authentication bypass exists via capture-replay that allows an unauthenticated third party to obtain paid resources by replaying a transfer settled by another payer. In the `MPP.Methods.Tempo` method, a settled TIP-20 TransferWithMemo is typically bound to a specific challenge using an attribution nonce in the memo. However, when a static memo is configured in `method config`, the `check matched memo binding/3` function returns a match unconditionally, skipping the binding process. This leaves only the token, recipient, amount, and static memo value for verification. Since the static memo is included in unauthenticated 402 responses and Tempo transfers are public, an attacker can use a transaction hash from a legitimate customer's transfer as a `type="hash"` credential for a new challenge. The hash path does not perform sender or signature checks to verify if the presenter owns the wallet that broadcast the transfer. **Recommendations** Update ZenHive mpp to version 0.6.4 or later. Avoid configuring a static memo in `method config` to ensure per-challenge attribution binding remains active.

**Name of the Vulnerable Software and Affected Versions** ZenHive mpp versions 0.3.0 through 0.6.2 **Description** An authentication bypass exists that allows an unauthenticated remote client to obtain paid resources by resubmitting a settled on-chain transfer. The `MPP.Methods.EVM.verify/2` function accepts a transaction-hash credential and matches a transfer based solely on the token, recipient, and amount for ERC-20 tokens, or the recipient and value for native tokens. Because the proof is not bound to the challenge being verified or to a record of prior use, and the `MPP.Plug` deduplication store keys are based on `challenge.id` (which is regenerated for every 402 response), a single historical transfer matching the charge can satisfy multiple subsequent charges. This allows an attacker to use transfers found on a public block explorer to bypass payment requirements on static-price routes. **Recommendations** Update ZenHive mpp to version 0.6.3 or later.

**Name of the Vulnerable Software and Affected Versions** ZenHive mpp versions 0.2.0 through 0.11.0 **Description** An unauthenticated remote client can drain the fee-payer wallet by initiating concurrent sponsored payments, leading to a denial of service for legitimate payers. The issue occurs because `MPP.Methods.Tempo.FeePayerPolicy` enforces budget ceilings—including `max gas`, `max fee per gas`, `max priority fee per gas`, and the `max total fee` budget cap—on a per-transaction basis rather than across concurrent requests. While the `reserve hash atomic/2` function prevents the duplicate broadcast of the same signed transaction, it does not prevent multiple distinct sponsored transactions with different expiring nonces. Consequently, the total sponsor exposure can reach N times the `max total fee`, and the default 900-second validity window allows these transactions to remain broadcastable and uncounted. **Recommendations** Update ZenHive mpp to version 0.12.0.

**Name of the Vulnerable Software and Affected Versions** ZenHive mpp versions 0.2.0 through 0.6.0 **Description** A Time-of-check Time-of-use (TOCTOU) race condition exists, allowing an unauthenticated remote client to redeem a single confirmed on-chain payment for multiple paid-resource accesses. This occurs in the `type="hash"` credential path within the `MPP.Methods.Tempo.verify/2` function, which uses a non-atomic check-then-mark sequence. Specifically, the `check hash unused/2` function reads the deduplication store, and after an `eth getTransactionReceipt` round trip verifies the payment on-chain, the `mark hash used/2` function writes the mark. Concurrent requests using the same settled payment hash can pass the initial read before any write occurs, resulting in multiple receipts. While an atomic `check and mark/2` primitive exists and is used by the `type="transaction"` path, the hash path incorrectly uses plain get and put operations. This issue requires a deduplication store to be configured, as the default nil store is stateless and provides no replay protection. **Recommendations** Update ZenHive mpp to version 0.6.1. As a temporary mitigation, restrict the use of the `type="hash"` credential path in `MPP.Methods.Tempo.verify/2` until the update is applied.

**Name of the Vulnerable Software and Affected Versions** mpp versions 0.2.0 through 0.5.9 **Description** Improper validation of input quantity allows an unauthenticated remote client to significantly inflate the gas cost per payment for the fee-payer, reducing the sponsor's operating margin. When the library is configured as a fee payer, the `cosign fee payer/3` function re-signs client-supplied base fields of the 0x76 AASigned envelope without validating the length or contents of the EIP-2930 access list. EIP-2930 access list entries incur intrinsic gas costs regardless of whether the addresses are used. A malicious client can submit a `transferWithMemo` call with numerous fabricated access-list entries, causing the fee-payer wallet to pay a large multiple of the expected gas cost. This can lead to the gradual draining of the fee-payer wallet. **Recommendations** Update mpp to version 0.6.0 or later. As a temporary mitigation, set the `fee payer` configuration to `false` to disable server-side gas sponsorship.

**Name of the Vulnerable Software and Affected Versions** mpp versions 0.2.0 through 0.5.9 **Description** Improper validation of input quantities allows an unauthenticated remote client to drain the fee-payer wallet, leading to a denial of service for legitimate clients. When the library is configured with `fee payer: true`, the `MPP.Methods.Tempo` payment method co-signs and broadcasts client-supplied EVM transactions without verifying if the `gas limit` is sufficient. An attacker can submit a `transferWithMemo` transaction with a `gas limit` set just below the required amount. The server broadcasts this via `rpc broadcast sync`, and although the transaction reverts due to running out of gas, the fee-payer wallet is charged for the burned gas. Additionally, the optimistic path where `wait for confirmation = false` is affected because the `simulate payment call` function via `eth call` omits the gas parameter, failing to detect out-of-gas conditions. **Recommendations** Update mpp to version 0.6.0 or later. As a temporary mitigation, set `fee payer` to `false` in the `MPP.Methods.Tempo` configuration to disable server-side gas sponsorship.

**Name of the Vulnerable Software and Affected Versions** mpp versions 0.2.0 through 0.5.9 **Description** Improper validation of input quantities allows an unauthenticated remote client to drain the fee-payer wallet in a single request by specifying an arbitrarily high gas price. When the library is configured as a fee payer, the `cosign fee payer/3` function re-signs client-supplied base fields of the 0x76 AASigned envelope without validating that `max fee per gas` and `max priority fee per gas` are within reasonable bounds. A malicious client can embed excessively large values for these variables, causing the server to pay inflated per-gas rates from its own wallet. This can result in the complete depletion of the wallet, preventing the server from sponsoring gas for legitimate requests. This issue is only reachable when the `MPP.Methods.Tempo` method is configured with `fee payer: true`. **Recommendations** Update mpp to version 0.6.0 or later. As a temporary mitigation, set the `fee payer` configuration to `false` to disable server-side gas sponsorship.