CVE-2026-63628 in mppx
Summary
by MITRE • 09/22/2026
mppx is a TypeScript interface for machine payments protocol. Prior to 0.8.2, the fee-payer cosigning path in src/tempo/internal/fee-payer.ts copied a client-supplied access_list from a 0x78 FeePayerEnvelope without validating its length or contents. Because EIP-2930 access-list entries consume intrinsic gas even when the listed addresses are never used, a client could add fabricated address-only entries and cause the server fee_payer wallet to pay unnecessary transaction fees. The demonstrated 180-entry list remained within the 500,000 gas policy cap, 16 KB header limit, and RPC simulation budget while increasing the fee by approximately 9.4 times. This issue is fixed in version 0.8.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in mppx versions prior to 0.8.2 represents a critical flaw in the transaction processing logic for machine payments, specifically within the fee-payer cosigning path located in src/tempo/internal/fee-payer.ts. This component is responsible for handling FeePayerEnvelope structures that include an access_list field defined by EIP-2930 standards. The core technical failure lies in the absence of validation logic when copying a client-supplied access list from this envelope. Instead of verifying the integrity, length, or content validity of the provided data structure, the implementation blindly copies the array into the transaction payload destined for signing and submission by the fee-payer wallet. This lack of input sanitization allows malicious actors to inject arbitrary data that is subsequently processed as valid protocol instructions without any scrutiny regarding its necessity or legitimacy.
The operational impact of this flaw stems directly from how Ethereum Virtual Machine (EVM) gas consumption rules apply to EIP-2930 access lists. According to the specification, each entry in an access list consumes intrinsic gas during transaction execution, regardless of whether the listed addresses and storage keys are actually accessed or modified by the smart contract logic involved. A malicious client can exploit this behavior by constructing a FeePayerEnvelope containing a fabricated access list filled with numerous address-only entries that serve no functional purpose for the actual transaction being executed. By doing so, the attacker forces the fee-payer wallet to incur significantly higher gas costs associated solely with processing these redundant data structures. This constitutes an economic denial-of-service attack against the entity responsible for paying fees, as they are compelled to spend substantially more resources than required by the legitimate business logic of the transaction.
In practical demonstrations, this vulnerability has been shown to allow a client to append an access list containing 180 fabricated entries while remaining within standard network constraints such as the RPC simulation budget and typical header size limits like the 16 KB limit for envelope headers. Despite staying under these technical thresholds, the inclusion of these unnecessary entries increased the total transaction fee by approximately nine point four times compared to a clean request. This amplification occurs because each access list entry adds a fixed amount of intrinsic gas cost per address and storage key pair processed during the initial phases of transaction execution. The attacker effectively leverages the trust placed in the client-supplied data structure to drain the financial resources of the fee-payer, creating an asymmetric attack vector where minimal effort from the adversary results in disproportionate economic loss for the victim.
This issue aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write if interpreted broadly as processing untrusted data without adequate bounds checking or semantic validation. From a threat modeling perspective, it reflects aspects of ATT&CK technique T1496 Resource Hijacking, where an attacker uses compromised resources to perform actions that benefit themselves while imposing costs on the victim. The vulnerability highlights the importance of strict input sanitization in financial transaction protocols, particularly when dealing with complex data structures like access lists that have direct implications for gas consumption and network fees.
To mitigate this risk, it is essential to implement rigorous validation checks before processing any client-supplied access list within the fee-payer cosigning path. Developers should enforce strict limits on the number of entries allowed in an access list based on reasonable expectations for legitimate transaction complexity. Additionally, each entry should be validated against known active contracts or expected interaction patterns rather than accepted blindly. Upgrading to version 0.8.2 resolves this issue by introducing these necessary safeguards. Organizations relying on mppx must ensure their systems are updated immediately to prevent exploitation of this economic denial-of-service vector and protect fee-payer wallets from unauthorized financial drain through manipulated transaction metadata.