CVE-2026-59252

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 (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. 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 wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, 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.

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 (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. 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 wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, 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.

Vulnerability

When the server acts as the fee payer, mpp Elixir 0.4.0 (ZenHive/mpp) does not validate whether the gas_limit set by the client is enough before broadcasting. A malicious client can drain the server's gas without paying.

A transferWithMemo call on Tempo Moderato testnet requires ~51,299 gas to complete successfully. By setting gas_limit = 51,298:

1. The Tx gets cosigned and broadcast by the server.
2. The Tx runs out of gas during EVM execution. All state reverts.
3. The server's fee-payer wallet is charged for gas used.
4. The client pays nothing and receives no resource.

# Run the PoC
unzip mpp_elixir_low_gas_PoC.zip
cd mpp_elixir_low_gas_PoC
docker build -t mpp-elixir-low-gas .
docker run --rm mpp-elixir-low-gas

Zero-Cost DoS Attack: Unlike gas draining with access list or padding, where the malicious client needs to complete a payment to drain the gas, this vulnerability allows malicious users to continuously drain the server's gas at virtually no financial cost (requiring only computing power). Therefore, an attacker can spawn N malicious clients to completely drain the funds from the server's wallet to perform a Denial of Service (DoS) attack. Once the server's wallet is empty, it has no more funds to pay the gas fees for upcoming requests from legitimate clients.

# Run the DoS PoC
unzip mpp_elixir_low_gas_dos_PoC.zip
cd mpp_elixir_low_gas_dos_PoC
docker build -t mpp-elixir-dos .
docker run --rm mpp-elixir-dos

Vulnerable code path: broadcast_and_verify/7 in mpp/methods/tempo.ex (ZenHive/mpp 0.4.0). When wait_for_confirmation = true (the default), it calls rpc_broadcast_sync directly without any gas-adequacy check or simulation. The alternative wait_for_confirmation = false path does call simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions.

Impact

A malicious client can drain the server's wallet without any financial cost.

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 (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. 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 wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, 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.

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 (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. 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 wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, 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.

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 (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. 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 wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, 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.

Summary

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 (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. 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 wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, 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.

Configurations

The vulnerable code path is only reachable when the MPP.Methods.Tempo method is configured with fee_payer: true (server-side gas sponsorship). Default deployments with fee_payer: false are not affected, since the client pays for gas out of its own wallet.

Vulnerability

When the server acts as the fee payer, mpp Elixir 0.4.0 (ZenHive/mpp) does not validate whether the gas_limit set by the client is enough before broadcasting. A malicious client can drain the server's gas without paying.

A transferWithMemo call on Tempo Moderato testnet requires ~51,299 gas to complete successfully. By setting gas_limit = 51,298:

1. The Tx gets cosigned and broadcast by the server.
2. The Tx runs out of gas during EVM execution. All state reverts.
3. The server's fee-payer wallet is charged for gas used.
4. The client pays nothing and receives no resource.

# Run the PoC
unzip mpp_elixir_low_gas_PoC.zip
cd mpp_elixir_low_gas_PoC
docker build -t mpp-elixir-low-gas .
docker run --rm mpp-elixir-low-gas

Zero-Cost DoS Attack: Unlike gas draining with access list or padding, where the malicious client needs to complete a payment to drain the gas, this vulnerability allows malicious users to continuously drain the server's gas at virtually no financial cost (requiring only computing power). Therefore, an attacker can spawn N malicious clients to completely drain the funds from the server's wallet to perform a Denial of Service (DoS) attack. Once the server's wallet is empty, it has no more funds to pay the gas fees for upcoming requests from legitimate clients.

# Run the DoS PoC
unzip mpp_elixir_low_gas_dos_PoC.zip
cd mpp_elixir_low_gas_dos_PoC
docker build -t mpp-elixir-dos .
docker run --rm mpp-elixir-dos

Vulnerable code path: broadcast_and_verify/7 in mpp/methods/tempo.ex (ZenHive/mpp 0.4.0). When wait_for_confirmation = true (the default), it calls rpc_broadcast_sync directly without any gas-adequacy check or simulation. The alternative wait_for_confirmation = false path does call simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions.

Impact

A malicious client can drain the server's wallet without any financial cost.