CVE-2026-82750
Fix: ZenHive/mpp@0482572CVE-2026-82750 is a CWE-1284 vulnerability in mpp. O3 Security confirms whether CVE-2026-82750 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Unbounded EIP-7702 authorization list in mpp Tempo fee-payer sponsorship inflates gas cost and sponsors account delegation
Real-World Exposure
mppReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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 EIP-7702 account delegations of the client's choosing.
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 never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.
This issue affects mpp: from 0.2.0 before 0.16.1.
Workaround
Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.
Configuration
Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | mpp | ≥ 0.2.0&&< 0.16.1 | 0.16.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mpp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update mpp to 0.16.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-82750 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-82750 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-82750. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-82750 in your dependencies?
O3 detects CVE-2026-82750 across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.