GHSA-vj8p-hp9x-gh47: Zero-Cost Fee-Payer Wallet Gas Draining in mpp Elixir Library

The mpp Elixir library (ZenHive/mpp) provides multi-party payments and transaction sponsorship services. When configured to act as a "fee payer" or transaction sponsor, the server takes a client's signed transaction envelope (typically type 0x76 on Tempo-enabled chains), co-signs it as the paying party, and broadcasts it to the EVM network. This architecture is designed to hide transaction fee complexity from end-users by paying native blockchain execution gas on their behalf.

The attack surface exists at the transaction submission endpoint. Because any unauthenticated client can request sponsorship, the server must strictly validate all input parameters in the transaction envelope. Prior to version 0.6.0, the library failed to validate whether the gas_limit specified by the client was sufficient for successful contract execution.

This flaw is classified under CWE-20 (Improper Input Validation). By supplying a gas_limit that is mathematically lower than the actual execution requirements, an attacker can trigger an on-chain execution revert. Because the transaction reverts, the attacker incurs no financial cost, while the sponsor's fee-paying wallet is charged for the wasted gas.

To understand the vulnerability, it is necessary to examine how mpp managed transaction confirmation paths. The system offered two dispatch routes: a synchronous path (wait_for_confirmation = true) and an optimistic asynchronous path (wait_for_confirmation = false). Both paths introduced critical validation gaps.

On the synchronous confirmation path, the library omitted simulation completely. It invoked the rpc_broadcast_sync function immediately after co-signing the transaction. This logic left the server entirely blind to the contract's actual execution parameters and runtime state, broadcasting raw hex data without pre-verification.

On the optimistic path, the library attempted validation via a private function named simulate_payment_call/3. However, this function was fundamentally flawed. It executed a standard eth_call targeting only the inner raw parameters (to and input calldata). It completely omitted the client-supplied gas_limit from the JSON-RPC payload, meaning the simulation node assumed default or infinite gas. Consequently, transactions with insufficient gas limits simulated as successful but failed catastrophically when executed on-chain.

The code-level mistake is located in lib/mpp/methods/tempo.ex. In the vulnerable implementation, the synchronous path executed a direct broadcast while the optimistic path used a flawed helper function:

# Vulnerable synchronous path (pre-0.6.0)
defp broadcast_and_verify(%Transaction{raw: raw_hex}, rpc_url, config, charge, memo, true, _payment_call) do
  rpc_opts = rpc_options(config)
  # Missing simulation check before broadcasting
  with {:ok, tx_hash, receipt} <- rpc_broadcast_sync(raw_hex, rpc_url, rpc_opts),
       :ok <- check_receipt_status(receipt),
       {:ok, _transfer} <- find_matching_transfer(receipt, charge, memo) do
    {:ok, tx_hash}
  end
end

The corresponding validation helper on the optimistic path was also ineffective because it simulated a bare contract call without copying the outer transaction metadata or specifying gas parameters:

# Vulnerable optimistic path simulation (pre-0.6.0)
defp simulate_payment_call(%{to: to, input: input}, rpc_url, config) do
  to_hex = "0x" <> Base.encode16(to, case: :lower)
  data_hex = "0x" <> Base.encode16(input, case: :lower)
  body = Jason.encode!(%{
    "jsonrpc" => "2.0",
    "method" => "eth_call",
    # Vulnerability: "gas" parameters are omitted completely
    "params" => [%{"to" => to_hex, "data" => data_hex}, "latest"],
    "id" => 1
  })
  # ... requests sent to JSON-RPC backend ...
end

To resolve this issue, the patch introduced in version 0.6.0 replaced these sections with a pre-broadcast transaction simulation using the standard eth_simulateV1 JSON-RPC method. This method processes the entire co-signed transaction envelope, ensuring that recovered senders, signature structures, and user-defined gas parameters are fully evaluated before any gas is committed on-chain.

An attacker can exploit this vulnerability with zero financial cost. To initiate the attack, the adversary must first identify a transaction that the target server is willing to sponsor. For instance, a basic contract call such as transferWithMemo on the Tempo Moderato network might require exactly 51,299 gas units to execute successfully.

The attacker crafts a custom 0x76 transaction envelope. Instead of setting the gas limit to 51,299, the attacker specifies a gas_limit of exactly 51,298 (one gas unit below the minimum runtime requirement). When this payload is sent to the vulnerable mpp endpoint, the server co-signs and broadcasts it.

During EVM block execution, the EVM processes the transaction up to its limit of 51,298 gas units. Because it lacks the final gas unit to write to state or complete execution, the EVM halts execution and throws an Out-of-Gas (OOG) error. All state changes associated with the user's action are reverted, meaning the attacker pays nothing. However, because the transaction was validly signed and broadcasted, the network still charges the sponsor's fee-payer wallet for the entire 51,298 gas burned prior to the failure.

Although the patch in version 0.6.0 is robust, security researchers must account for several architectural nuances when auditing this implementation.

To ensure compatibility with older EVM RPC endpoints that do not implement standard Account Abstraction simulation protocols, the developers added a graceful degradation path. If the RPC node returns a JSON-RPC error code of -32601 (method not found) for eth_simulateV1, the server records an info log and continues to broadcast the transaction anyway:

{:ok, :unsupported} ->
  Logger.info("MPP.Methods.Tempo: node does not implement eth_simulateV1; skipping pre-broadcast simulation")
  :ok

This design decision introduces a fallback vulnerability. If an attacker can force the server's RPC queries to route to an older node, or if an administrator unknowingly deploys the package against a legacy node, the gas-draining protection is completely disabled.

Additionally, simulation is bound to the Time-of-Check to Time-of-Use (TOCTOU) problem. A transaction may simulate successfully against the state of block N, but if another transaction modifies contract state in the same block before the sponsored transaction is mined, the transaction may still revert on-chain. While this is an inherent limitation of EVM environments, it represents a potential vector for targeted exploit scenarios.

Remediation of this vulnerability requires upgrading the mpp package to version 0.6.0 or higher. This upgrade forces the dependent library onchain_tempo to version 0.7.0 which contains the necessary logic to structure eth_simulateV1 calls.

To apply the update, modify your Elixir configuration in mix.exs:

def deps do
  [
    {:mpp, "~> 0.6.0"}
  ]
end

Once updated, execute mix deps.update mpp and ensure your lockfile registers the correct version. Developers should also verify that their upstream JSON-RPC node provider fully supports the eth_simulateV1 method. If the node logs the skipping pre-broadcast simulation warning, the service remains exposed to wallet exhaustion.