GHSA-vj8p-hp9x-gh47: Input Validation

Published Sep 25, 2026
·
Updated

Vulnerability When the server acts as the fee payer, mpp Elixir 0.4.0 (ZenHive/mpp) does not validate whether the gaslimit 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 gaslimit = 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.

bash Run the PoC unzip mppelixirlowgasPoC.zip cd mppelixirlowgasPoC 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.

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

Vulnerable code path: broadcastandverify/7 in mpp/methods/tempo.ex (ZenHive/mpp 0.4.0). When waitforconfirmation = true (the default), it calls rpcbroadcastsync directly without any gas-adequacy check or simulation. The alternative waitforconfirmation = false path does call simulatepaymentcall via ethcall, 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.

Affected Software

1 affected componentFixes available
erlang/mpp>=0.2.0<0.6.0
0.6.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade erlang/mpp to a version that resolves this vulnerability.

    Fixed in 0.6.0

Event History

Sep 25, 2026
Advisory Published
via GitHub·09:47 PM
Data Sourced
via GitHub·09:47 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Servers using mpp Elixir as the fee payer are exposed. A malicious client can submit transactions with an insufficient gas_limit, causing the server's fee-payer wallet to spend gas while the transaction reverts.

2

What does an attacker need to exploit it?

The attacker needs to act as a client and set gas_limit below the amount needed for execution. For the described transferWithMemo example on Tempo Moderato testnet, a limit of 51,298 gas causes an out-of-gas failure while approximately 51,299 gas is required to succeed.

3

Does the attacker need to pay for the failed transaction?

No. The described attack causes the server's fee-payer wallet to be charged for gas used, while the client pays nothing and receives no resource because the transaction state reverts.

4

What is the operational impact?

Attackers can repeatedly submit underfunded transactions, potentially using many clients in parallel, to drain the server wallet and deny service. The advisory describes this as a virtually zero-cost attack for the client apart from computing power.

5

What should be changed to prevent exploitation?

Validate that the client-provided gas_limit is sufficient before cosigning and broadcasting a transaction when the server pays fees. The provided references include a fix commit and a v0.6.0 release.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203