GHSA-v858-xh7w-8jr5: pympp: Gas Draining with padding
pympp is a Python SDK for the Machine Payments Protocol. Prior to version 0.9.1, when the server acts as the feepayer, pympp validates calldata using ethabi decoding, which is lenient about trailing bytes. The FeePayerPolicy caps gaslimit (≤ 2 M) and maxfeepergas (≤ 100 Gwei) but does not check calldata length. Tempo uses legacy calldata gas pricing: 16 gas per non-zero byte. Appending N bytes of 0x01 padding inflates actual gas used by N × 16 while keeping gaslimit and maxfeepergas within policy caps. The server cosigns and broadcasts the padded transaction, draining its fee-payer wallet. This issue has been patched in version 0.9.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pymppto a version that resolves this vulnerability.Fixed in 0.9.1
Event History
Frequently Asked Questions
Which deployments are exposed to fee-payer wallet draining?
Deployments using pympp versions earlier than 0.9.1 are exposed when the server acts as the fee_payer. The issue affects transactions whose calldata can include appended non-zero padding.
What does an attacker need to exploit this issue?
An attacker needs network access to submit a transaction that the fee-payer server will cosign and broadcast. No privileges or user interaction are required according to the provided vector.
Why do the existing fee policy caps not prevent the extra charge?
The policy caps gas_limit at 2 M and max_fee_per_gas at 100 Gwei, but it does not validate calldata length. Appended 0x01 bytes add 16 gas each under Tempo's legacy calldata gas pricing without changing those capped fields.
What is the remediation?
Upgrade pympp to version 0.9.1, which patches the issue.