CVE-2026-82751 in mpp
Summary
by MITRE • 09/06/2026
Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.
When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.
This issue affects mpp: from 0.2.0 before 0.16.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/06/2026
The vulnerability identified in ZenHive's Multi-Payment Protocol (MPP) implementation represents a critical failure in input validation and state management within the fee-payer sponsorship logic. Specifically, the flaw resides in the Mpp.Methods.Tempo.FeePayerPolicy.measure/3 function located in lib/mpp/methods/tempo/fee_payer_policy.ex. This component is responsible for validating and bounding various parameters of client-signed 0x76 envelopes when a server acts as the fee payer. While the implementation correctly enforces limits on gas fields, total fee budgets, validity windows, and access lists, it fails to inspect or restrict the presence of optional key_authorization fields within these envelopes. This oversight allows an unauthenticated remote attacker to exploit the sponsorship mechanism by attaching a fully signed key authorization payload alongside standard payment instructions. The system processes this additional data without verifying whether such operations should be permitted under current policy constraints, leading to unauthorized state modifications and excessive resource consumption.
From a technical perspective, the core issue is a lack of validation for optional fields that trigger persistent storage writes. When an attacker includes a key_authorization field in their envelope, the protocol provisions a new access key with token spending limits on the client's account. These operations are treated as intrinsic gas costs and are billed to the fee payer rather than the transaction initiator. The system only checks if these additional costs fit within the predefined gas_limit ceiling but does not verify if provisioning keys is an allowed action for sponsored transactions. Consequently, a single malicious request can inflate the gas cost per sponsored payment by a significant multiplier. In reported instances involving one key with three token limits, the sponsored cost escalates from approximately 46,587 gas to roughly 1,808,700 gas. This represents an increase of nearly forty times the expected baseline cost, effectively allowing the attacker to drain the fee payer's resources while gaining persistent access credentials without incurring any direct financial liability themselves.
The operational impact of this vulnerability is severe for both service providers and end-users relying on sponsored transactions. For fee payers, such as exchanges or wallet services that subsidize user gas fees, this flaw enables a denial-of-service attack through economic exhaustion. Attackers can systematically submit requests designed to maximize key provisioning costs, rapidly depleting the sponsor's funds. Simultaneously, attackers gain unauthorized access keys on their own accounts, which may be leveraged for further malicious activities or sold in underground markets. This dual impact undermines the integrity of the sponsorship model and compromises the security posture of the ecosystem by introducing unvalidated state changes that bypass intended policy restrictions. The vulnerability affects versions of mpp from 0.2.0 up to but not including version 0.16.1, indicating a long-standing issue in the protocol's core logic if left unpatched.
This incident aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write when considering the unintended state modifications resulting from unchecked optional fields. It also maps to MITRE ATT&CK techniques related to Resource Hijacking, specifically T1496 Remote Service Abuse or T1534 Internal Spearphishing if used for lateral movement within a broader attack chain involving compromised accounts. To mitigate this risk, developers must implement strict validation rules that explicitly check for and reject optional key_authorization fields in sponsored envelopes unless such actions are explicitly whitelisted by policy. Additionally, the fee calculation logic should account for all potential state-changing operations triggered by envelope contents, ensuring that intrinsic gas costs associated with key provisioning are either prohibited or strictly capped independent of general gas limits. Updating to version 0.16.1 or later resolves this issue as it includes the necessary fixes for input validation and policy enforcement in the fee payer measurement logic.