GHSA-6FJM-7MV9-C325
Vulnerability from github – Published: 2026-09-06 18:34 – Updated: 2026-09-06 18:34Improper 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.
{
"affected": [],
"aliases": [
"CVE-2026-82751"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-06T17:17:56Z",
"severity": "HIGH"
},
"details": "Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer\u0027s gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client\u0027s own account.\n\nWhen 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\u0027s 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.1.",
"id": "GHSA-6fjm-7mv9-c325",
"modified": "2026-09-06T18:34:38Z",
"published": "2026-09-06T18:34:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-rpwj-vrf7-4x36"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82751"
},
{
"type": "WEB",
"url": "https://github.com/ZenHive/mpp/commit/0482572b47e1ffe1537ab80ab613d47b92833c2d"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-82751.html"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-82751"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.