{"api_version":"1","generated_at":"2026-07-18T00:39:31+00:00","cve":"CVE-2026-59252","urls":{"html":"https://cve.report/CVE-2026-59252","api":"https://cve.report/api/cve/CVE-2026-59252.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-59252","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-59252"},"summary":{"title":"Missing gas_limit validation in mpp Tempo fee-payer enables wallet drain","description":"Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients.\n\nWhen the mpp Elixir library is configured as fee payer (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests.\n\nThe wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions.\n\nThis issue affects mpp: from 0.2.0 before 0.6.0.","state":"PUBLISHED","assigner":"EEF","published_at":"2026-07-17 11:17:13","updated_at":"2026-07-17 18:09:55"},"problem_types":["CWE-1284","CWE-1284 CWE-1284 Improper Validation of Specified Quantity in Input"],"metrics":[{"version":"4.0","source":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","type":"Secondary","score":"8.2","severity":"HIGH","vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/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","data":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/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","baseScore":8.2,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}},{"version":"4.0","source":"CNA","type":"CVSS","score":"8.2","severity":"HIGH","vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","data":{"attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"NETWORK","baseScore":8.2,"baseSeverity":"HIGH","privilegesRequired":"NONE","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","vectorString":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE"}}],"references":[{"url":"https://github.com/ZenHive/mpp/security/advisories/GHSA-vj8p-hp9x-gh47","name":"https://github.com/ZenHive/mpp/security/advisories/GHSA-vj8p-hp9x-gh47","refsource":"134c704f-9b21-4f2e-91b3-4a467353bcc0","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://cna.erlef.org/cves/CVE-2026-59252.html","name":"https://cna.erlef.org/cves/CVE-2026-59252.html","refsource":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-59252","name":"https://osv.dev/vulnerability/EEF-CVE-2026-59252","refsource":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/ZenHive/mpp/commit/d84e3e528db39654540c2035ea0fbdf7b950d3d1","name":"https://github.com/ZenHive/mpp/commit/d84e3e528db39654540c2035ea0fbdf7b950d3d1","refsource":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-59252","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-59252","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"ZenHive","product":"mpp","version":"affected 0.2.0 0.6.0 semver","platforms":[]},{"source":"CNA","vendor":"ZenHive","product":"mpp","version":"affected d29d54e507918db00a5b65d90136b73166c017d7 d84e3e528db39654540c2035ea0fbdf7b950d3d1 git","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Kian Kai Ang","lang":"en"},{"source":"CNA","value":"E.FU","lang":"en"},{"source":"CNA","value":"Jonatan Männchen / EEF","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"metrics":[{"other":{"content":{"id":"CVE-2026-59252","options":[{"Exploitation":"poc"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","timestamp":"2026-07-17T12:21:12.801804Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-07-17T12:21:18.794Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"references":[{"tags":["exploit"],"url":"https://github.com/ZenHive/mpp/security/advisories/GHSA-vj8p-hp9x-gh47"}],"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"collectionURL":"https://repo.hex.pm","cpes":["cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.MPP.Methods.Tempo'"],"packageName":"mpp","packageURL":"pkg:hex/mpp","product":"mpp","programFiles":["lib/mpp/methods/tempo.ex"],"programRoutines":[{"name":"'Elixir.MPP.Methods.Tempo':broadcast_and_verify/7"}],"repo":"https://github.com/ZenHive/mpp","vendor":"ZenHive","versions":[{"lessThan":"0.6.0","status":"affected","version":"0.2.0","versionType":"semver"}]},{"collectionURL":"https://github.com","cpes":["cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"],"defaultStatus":"unaffected","modules":["'Elixir.MPP.Methods.Tempo'"],"packageName":"ZenHive/mpp","packageURL":"pkg:github/ZenHive/mpp","product":"mpp","programFiles":["lib/mpp/methods/tempo.ex"],"programRoutines":[{"name":"'Elixir.MPP.Methods.Tempo':broadcast_and_verify/7"}],"repo":"https://github.com/ZenHive/mpp","vendor":"ZenHive","versions":[{"lessThan":"d84e3e528db39654540c2035ea0fbdf7b950d3d1","status":"affected","version":"d29d54e507918db00a5b65d90136b73166c017d7","versionType":"git"}]}],"configurations":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>The vulnerable code path is only reachable when the <tt>MPP.Methods.Tempo</tt> method is configured with <tt>fee_payer: true</tt> (server-side gas sponsorship). Default deployments with <tt>fee_payer: false</tt> are not affected, since the client pays for gas out of its own wallet.</p>"}],"value":"The vulnerable code path is only reachable when the MPP.Methods.Tempo method is configured with fee_payer: true (server-side gas sponsorship). Default deployments with fee_payer: false are not affected, since the client pays for gas out of its own wallet."}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*","versionEndExcluding":"0.6.0","versionStartIncluding":"0.2.0","vulnerable":true}],"negate":false,"operator":"AND"}],"operator":"OR"}],"credits":[{"lang":"en","type":"finder","value":"Kian Kai Ang"},{"lang":"en","type":"remediation developer","value":"E.FU"},{"lang":"en","type":"analyst","value":"Jonatan Männchen / EEF"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients.</p><p>When the <tt>mpp</tt> Elixir library is configured as fee payer (<tt>fee_payer: true</tt>), the <tt>MPP.Methods.Tempo</tt> payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied <tt>gas_limit</tt> is sufficient to complete the intended call. A malicious client can submit a signed <tt>transferWithMemo</tt> transaction with <tt>gas_limit</tt> deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via <tt>rpc_broadcast_sync</tt>. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests.</p><p>The <tt>wait_for_confirmation = false</tt> (optimistic) path is also affected: it invokes <tt>simulate_payment_call</tt> via <tt>eth_call</tt>, but that simulation omits the <tt>gas</tt> parameter and therefore does not catch out-of-gas conditions.</p><p>This issue affects mpp: from 0.2.0 before 0.6.0.</p>"}],"value":"Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients.\n\nWhen the mpp Elixir library is configured as fee payer (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests.\n\nThe wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions.\n\nThis issue affects mpp: from 0.2.0 before 0.6.0."}],"impacts":[{"capecId":"CAPEC-130","descriptions":[{"lang":"en","value":"CAPEC-130 Excessive Allocation"}]}],"metrics":[{"cvssV4_0":{"attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"NETWORK","baseScore":8.2,"baseSeverity":"HIGH","privilegesRequired":"NONE","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","vectorString":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-1284","description":"CWE-1284 Improper Validation of Specified Quantity in Input","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-07-17T10:11:54.436Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"tags":["vendor-advisory","related"],"url":"https://github.com/ZenHive/mpp/security/advisories/GHSA-vj8p-hp9x-gh47"},{"tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-59252.html"},{"tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-59252"},{"tags":["patch"],"url":"https://github.com/ZenHive/mpp/commit/d84e3e528db39654540c2035ea0fbdf7b950d3d1"}],"source":{"discovery":"EXTERNAL"},"title":"Missing gas_limit validation in mpp Tempo fee-payer enables wallet drain","x_generator":{"engine":"cvelib 1.8.0"}}},"cveMetadata":{"assignerOrgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","assignerShortName":"EEF","cveId":"CVE-2026-59252","datePublished":"2026-07-17T10:11:54.436Z","dateReserved":"2026-07-04T04:24:03.653Z","dateUpdated":"2026-07-17T12:21:18.794Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-17 11:17:13","lastModifiedDate":"2026-07-17 18:09:55","problem_types":["CWE-1284","CWE-1284 CWE-1284 Improper Validation of Specified Quantity in Input"],"metrics":{"cvssMetricV40":[{"source":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/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","baseScore":8.2,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-07-17T12:21:12.801804Z","id":"CVE-2026-59252","options":[{"exploitation":"poc"},{"automatable":"no"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"59252","Ordinal":"1","Title":"Missing gas_limit validation in mpp Tempo fee-payer enables wall","CVE":"CVE-2026-59252","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"59252","Ordinal":"1","NoteData":"Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet, resulting in denial of service for legitimate clients.\n\nWhen the mpp Elixir library is configured as fee payer (fee_payer: true), the MPP.Methods.Tempo payment method co-signs and broadcasts a client-supplied EVM transaction without first validating that the client-supplied gas_limit is sufficient to complete the intended call. A malicious client can submit a signed transferWithMemo transaction with gas_limit deliberately set just below the amount required for successful execution. The server co-signs the transaction and broadcasts it via rpc_broadcast_sync. The transaction runs out of gas during EVM execution and reverts, but the fee-payer wallet is still charged for the burned gas while the client pays nothing and receives no resource. Repeated requests from one or more malicious clients drain the fee-payer wallet at near-zero cost to the attacker, ultimately preventing the server from sponsoring gas for legitimate payment requests.\n\nThe wait_for_confirmation = false (optimistic) path is also affected: it invokes simulate_payment_call via eth_call, but that simulation omits the gas parameter and therefore does not catch out-of-gas conditions.\n\nThis issue affects mpp: from 0.2.0 before 0.6.0.","Type":"Description","Title":"Missing gas_limit validation in mpp Tempo fee-payer enables wall"}]}}}