GHSA-vv77-66rf-pm86: Gas Draining Vulnerability in mpp Multi-Party Payments Library

The Elixir package mpp provides Multi-Party Payment handling and transaction protocol capabilities. When acting as a sponsored transaction gateway, the service acts as a fee payer, co-signing client transactions and broadcasting them to the Ethereum network.

Under this model, the service operator commits to covering the gas costs associated with user transactions, facilitating frictionless interactions for end-users. However, this architectural design exposes a significant attack surface if input verification is solely limited to checking the transaction destination and cryptographic signature.

Prior to version 0.6.0, the mpp library failed to evaluate the gas economics metrics of incoming transaction envelopes before initiating the co-signing process. This lack of checking constitutes a severe input validation flaw, categorizable under CWE-20.

The root cause of the vulnerability lies in the implementation of the cosign_fee_payer/3 function inside lib/mpp/methods/tempo.ex. The function verified that the transaction parameters matched an expected destination address and call data scope (the allowed interactions), but it performed no evaluation on the gas parameters encoded in the RLP envelope.

Specifically, the RLP indices corresponding to gas_limit, max_fee_per_gas, max_priority_fee_per_gas, and the access_list were processed and signed without any bounding checks. In EVM-compatible networks, the final cost of a transaction is determined by the actual gas consumed multiplied by the effective gas price, bounded by the parameters defined in the transaction envelope.

Because the library did not enforce a maximum ceiling on these fields, a client could provide a signed 0x76 envelope with extremely large values. When the server signed the envelope as the fee payer, it legally committed its wallet to paying those fees upon block execution, allowing the transaction to be mined at an inflated rate.

The vulnerability was resolved by introducing a validation layer before the cryptographic signing phase. The updated pipeline in lib/mpp/methods/tempo.ex incorporates a call to maybe_validate_fee_payer_economics/3.

# In lib/mpp/methods/tempo.ex
# Validation step added prior to co-signing
defp maybe_validate_fee_payer_economics(tx, %{"fee_payer" => true} = config, chain_id) do
  policy = FeePayerPolicy.resolve(chain_id, config["fee_payer_policy"])
  FeePayerPolicy.validate(tx, policy)
end
defp maybe_validate_fee_payer_economics(_tx, _config, _chain_id), do: :ok

The validation is executed by the newly added MPP.Methods.Tempo.FeePayerPolicy module. This module defines maximum bounds and performs a series of safety checks on the raw RLP-decoded elements. The critical fields checked include:

• gas_limit (checked against max_gas limit)
• max_fee_per_gas (checked against max_fee_per_gas limit)
• Cumulative Fee Cap: The product of gas_limit * max_fee_per_gas must not exceed max_total_fee (defaulting to 0.05 ETH).

# In lib/mpp/methods/tempo/fee_payer_policy.ex
def validate(%Transaction{} = tx, %__MODULE__{} = policy, now) when is_integer(now) do
  with {:ok, gas_limit} <- field_int(tx, @gas_limit_index, "gas_limit"),
       {:ok, max_fee} <- field_int(tx, @max_fee_index, "max_fee_per_gas"),
       {:ok, max_priority} <- field_int(tx, @max_priority_fee_index, "max_priority_fee_per_gas"),
       :ok <- check_gas(gas_limit, policy),
       :ok <- check_max_fee(max_fee, policy),
       :ok <- check_total_fee(gas_limit, max_fee, policy),
       :ok <- check_priority(max_priority, max_fee, policy),
       :ok <- check_nonce_key(tx),
       :ok <- check_validity_window(tx, policy, now) do
    check_access_list(tx)
  end
end

Additionally, the patch enforces that the access_list must be empty, removing the potential for payload padding, and implements strict validity time-windows to prevent replay or delayed broadcast attacks.

An attacker can exploit this vulnerability by executing a series of precise on-chain and off-chain steps. First, they construct a valid transaction envelope of type 0x76 containing a legitimate call to a supported contract.

Next, the attacker modifies the transaction's RLP-encoded gas parameters. They set the max_fee_per_gas and max_priority_fee_per_gas to artificially high levels (such as 100 Gwei or even multiple Ether per gas unit), or append a massive, redundant list of addresses to the access_list structure.

When this payload is submitted to the target server's API, the server validates the call destination but ignores the gas parameters. The server then signs the transaction envelope and broadcasts it. Upon inclusion in a block, the network deducts the inflated transaction fees directly from the server's co-signing wallet, resulting in an immediate and irreversible loss of native tokens.

The primary impact of this vulnerability is severe financial loss. Because transactions on EVM-compatible public networks are irreversible, funds transferred to block proposers and validators as transaction fees cannot be recovered.

Furthermore, the exploitation path requires no authentication or specific preconditions, representing a low-barrier, high-impact vector. Once the server's wallet balance is depleted below the minimum gas threshold, the service can no longer sponsor legitimate user transactions, leading to a permanent and complete Denial of Service (DoS) for all clients.

The CVSS v4 score is calculated as 8.8 (High) due to the combination of low attack complexity, network accessibility, no required privileges, and high integrity and availability impacts.

The recommended remediation is to immediately upgrade the mpp dependency in the Elixir application's mix.exs configuration to version 0.6.0 or higher.

# Update your mix.exs dependencies
defp deps do
  [
    {:mpp, "~> 0.6.0"}
  ]
end

If upgrading is not immediately feasible, operators must implement manual validation of the incoming transaction envelopes. Specifically, before passing a client-provided binary to cosign_fee_payer/3, decode the envelope and ensure the gas limit and gas price parameters fall within safe, hardcoded operational limits.

Additionally, implementing rate limiting on the transaction submission endpoints and closely monitoring the native balance of the fee-paying wallet will help reduce the window of exposure and minimize potential financial damages.