GHSA-QPXH-FF8M-C62V: Gas Draining and Resource Exhaustion in ZenHive mpp Library

The Multi-Payment Protocol (mpp) library developed by ZenHive provides Elixir-based multi-payment utilities for Ethereum Virtual Machine (EVM) networks. A core feature of this library is the support for 'Tempo' transactions, which are custom-defined, sponsored payment envelopes utilizing the 0x76 protocol type. Under this model, the server acts as a fee payer or gas sponsor, co-signing user-generated transactions and broadcasting them to the network. The sponsoring server incurs all gas fees associated with the transaction, relying on strict structural and economic policies to prevent abuse.\n\nA critical security flaw was identified in the verification mechanism of the Tempo protocol implementation prior to version v0.6.0. The server-side transaction parser fails to validate the presence or size of an EIP-2930 access list within the client-signed envelope. This missing boundary check exposes the gas-sponsor hot wallet to unrestricted financial drain. Because EIP-2930 access lists carry predefined upfront intrinsic gas fees, an attacker can manipulate the list of addresses to artificially inflate transaction costs.\n\nThe vulnerability falls under the class of Uncontrolled Resource Consumption (CWE-400) and Improper Input Validation (CWE-20). By submitting structurally valid but economically padded transactions, an attacker causes the server's wallet to pay for empty computations. This results in direct financial loss to the service operator and can completely deplete the sponsor's native gas tokens, resulting in a Denial of Service.

To understand the root cause of this vulnerability, it is necessary to examine how Ethereum Virtual Machine (EVM) nodes calculate gas for EIP-2930 transactions. When a transaction specifies an EIP-2930 access list, the EVM pre-warms the declared addresses and storage keys to reduce execution-time gas costs. However, to offset the overhead of pre-warming, the protocol charges a fixed upfront fee of 2,400 gas for every address and 1,900 gas for every storage key declared. These fees are charged as part of the transaction's intrinsic gas cost, which must be paid fully by the transaction sender before execution.\n\nIn the mpp library's custom 0x76 'Tempo' envelope, the transaction is structured using Recursive Length Prefix (RLP) serialization. The envelope contains several fields, with the fifth index reserved for the EIP-2930 compliant access list. During normal operations, the client constructs the transaction, signs it, and sends it to the mpp server. The server, acting as the fee payer, co-signs the envelope using its own private key and submits it to the EVM network via JSON-RPC, assuming full responsibility for the total transaction fees.\n\nThe vulnerability arises because the server's verification logic before version v0.6.0 completely ignores the access list field during validation. The server parses the RLP envelope but never inspects index 5 to confirm if it is empty. This omission allows a malicious client to supply an access list stuffed with hundreds of dummy addresses. When the server co-signs and broadcasts the transaction, the blockchain network bills the server's hot wallet for the inflated intrinsic gas costs, regardless of whether the transaction logic actually interacts with those addresses.

The vulnerable version of the library fails to perform checks on the access list field before executing the co-signing logic. In the core transaction processing module, lib/mpp/methods/tempo.ex, the transaction flow evaluates call scopes and immediately proceeds to sign the payload if the scope is valid. There are no functions to analyze gas parameters or structural fields of the RLP envelope, leaving the fee payer exposed to arbitrary transaction parameters.\n\nThe ZenHive development team resolved this issue in commit 5d6338e2334084c5f2a78cfcca474830733ed7e8 by introducing the MPP.Methods.Tempo.FeePayerPolicy module. This module executes a strict validation pass before any co-signing operation occurs. It enforces structural and quantitative checks on gas limits, fee rates, and transaction formatting. The critical patch logic intercepts the transaction payload and specifically inspects the access list field to ensure it is empty.\n\nThe following code block shows the added validation logic within lib/mpp/methods/tempo/fee_payer_policy.ex:\n\nelixir\n# 0x76 RLP envelope field indices\n@access_list_index 5\n\n@spec validate(Transaction.t(), t(), integer()) :: :ok | {:error, String.t()}\ndef validate(%Transaction{} = tx, %__MODULE__{} = policy, now) when is_integer(now) do\n with {:ok, gas_limit} <- field_int(tx, @gas_limit_index, \"gas_limit\"),\n {:ok, max_fee} <- field_int(tx, @max_fee_index, \"max_fee_per_gas\"),\n :ok <- check_gas(gas_limit, policy),\n :ok <- check_max_fee(max_fee, policy),\n :ok <- check_total_fee(gas_limit, max_fee, policy),\n :ok <- check_nonce_key(tx) do\n check_access_list(tx)\n end\nend\n\n@spec check_access_list(Transaction.t()) :: :ok | {:error, String.t()}\ndefp check_access_list(%Transaction{fields: fields}) do\n case Enum.at(fields, @access_list_index) do\n list when is_list(list) and list != [] ->\n {:error, \"fee-payer transaction must not declare an access list (\" <> to_string(length(list)) <> \" entries)\"}\n _ ->\n :ok\n end\nend\n\n\nThis implementation is complete and robust because sponsored transactions handled by the mpp gateway are designed for simple multi-payment functions. These standard payments do not interact with complex, re-entrant smart contracts that require access lists for state warming. By enforcing that the access list must be empty, the library prevents any padding attacks while retaining full compatibility with standard on-chain payment pathways.

To execute the gas draining attack, an adversary must identify an active mpp-based gateway server that has the fee sponsorship feature enabled. The attacker does not need any administrative privileges or authenticated access, as the gateway is designed to accept client-signed transactions for sponsorship. The adversary constructs a standard multi-payment request but modifies the underlying RLP structure to exploit the lack of validation.\n\nThe attacker generates a series of arbitrary, inactive Ethereum addresses and pairs them with empty storage key arrays to format a valid EIP-2930 access list structure. This payload is inserted into index 5 of the 0x76 transaction envelope. The adversary then signs the envelope with their user key and submits it to the vulnerable mpp server's transaction endpoint. A single transaction payload can include hundreds of dummy addresses, exponentially multiplying the upfront cost.\n\nWhen the unpatched server receives this payload, it validates the call scope, which appears completely legitimate because the target smart contract call is unmodified. The server co-signs the envelope using its sponsored hot wallet key and broadcasts the fully signed transaction to the blockchain RPC node. The EVM network validates the signature and deducts the intrinsic gas fees—including the 2,400 gas fee per dummy address—directly from the server's wallet. The attacker spends zero native tokens, while the sponsor suffers significant, immediate financial loss.\n\nA simplified flow of this attack is described in the diagram below:\n\nmermaid\ngraph LR\n Attacker[\"Attacker\"]\n VulnerableServer[\"Vulnerable mpp Server\"]\n Blockchain[\"EVM Blockchain Node\"]\n \n Attacker -- \"Sends 0x76 Envelope with Padded Access List\" --> VulnerableServer\n VulnerableServer -- \"Co-signs & Broadcasts Transaction\" --> Blockchain\n Blockchain -- \"Deducts Intrinsic Gas (2,400 per address) from Sponsor Wallet\" --> VulnerableServer\n

The impact of GHSA-QPXH-FF8M-C62V is categorized as a high-severity economic denial of service and direct financial theft. Because transaction fees on EVM-compatible networks are settled in native gas tokens that possess real-world fiat value, any inflation of transaction fees translates directly into monetary loss for the hosting platform. An attacker can repeatedly execute this process, draining thousands of dollars in native assets within minutes.\n\nBeyond direct financial loss, the vulnerability serves as a highly effective denial-of-service vector against the platform's payment services. EVM accounts must maintain a minimum balance of native tokens to pay for transactions. Once the attacker succeeds in depleting the sponsor's hot wallet, the server is unable to pay for subsequent transaction gas fees. This causes all legitimate client transaction submissions to fail due to insufficient fund errors on-chain.\n\nThis vulnerability is particularly dangerous because there is no symmetric cost for the attacker. The attacker does not pay any gas fees for the rejected or bloated transactions, as the server acts as the transaction sender and co-signer. This complete economic asymmetry allows a low-capability threat actor to automate the attack script, continuously draining the host wallet as long as it contains funds. This makes the vulnerability highly attractive for automated exploitation.

Remediation of this vulnerability requires upgrading the mpp library to version v0.6.0 or higher. This release integrates the MPP.Methods.Tempo.FeePayerPolicy which is active by default whenever the server acts as a fee payer. To apply the fix, developers must update their Elixir dependencies in the mix.exs configuration file and run the dependency fetch command.\n\nIn mix.exs, ensure the dependency specification reflects the secure version range:\n\nelixir\ndefp deps do\n [\n {:mpp, \"~> 0.6.0\"}\n ]\nend\n\n\nAfter modifying the dependency configuration, developers should execute mix deps.get and compile the application. No code changes are required in the application layer if developers are using the default configuration settings, as the new policy automatically intercepts and validates all inbound Tempo transactions.\n\nFor temporary mitigation on systems where an immediate library upgrade is not feasible, operators can disable the fee-payer feature entirely by setting the fee_payer configuration key to false in their environment configuration. This forces clients to cover their own gas fees and prevents the server wallet from being exposed to the padding attack. Additionally, operators should implement rate-limiting and access control mechanisms on their transaction submission endpoints to detect and block abnormal request volumes.