CVE-2026-82751
Fix: ZenHive/mpp@0482572CVE-2026-82751 is a CWE-1284 vulnerability in mpp. O3 Security confirms whether CVE-2026-82751 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Unbounded key authorization in mpp Tempo fee-payer sponsorship inflates gas cost and sponsors access-key provisioning
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 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.
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 carrying a key authorization 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-82751 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-82751 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-82751. 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-82751 in your dependencies?
O3 detects CVE-2026-82751 across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.