Description
Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.
Published: 2026-08-19
Score: 8.3 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

An unauthenticated remote client can exploit a resource allocation flaw in ZenHive mpp's Tempo FeePayerPolicy, allowing multiple concurrent sponsored payments to drain the fee‑payer wallet. The policy limits resource usage per individual transaction but does not account for aggregate exposure across concurrent requests, thereby allowing the sponsor wallet to be depleted by several concurrent transactions. This vulnerability, classified as CWE‑770, can lead to loss of funds and denial of service for legitimate payers once the sponsor wallet is empty.

Affected Systems

The issue impacts ZenHive mpp versions starting from 0.2.0 up to, but not including, 0.12.0. Only the mpp library is affected; the vulnerability is tied to its Tempo.FeePayerPolicy component and the reserve_hash_atomic/2 mechanism that prevents duplicate broadcasts of the same signed transaction but not distinct sponsored transactions with different expiring nonces.

Risk and Exploitability

The CVSS score of 8.3 indicates high severity, but no EPSS score is available, so the current exploitation probability cannot be quantified. The vulnerability is not listed in the CISA KEV catalogue. An attacker would need network access to the mpp service, the ability to send sponsored payment transactions, and the capacity to issue them concurrently to fully drain the sponsor wallet. Successful exploitation would compromise confidentiality and integrity of the sponsor wallet and cause availability disruption for all legitimate payment users.

Generated by OpenCVE AI on August 20, 2026 at 13:29 UTC.

Remediation

Vendor Workaround

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.


OpenCVE Recommended Actions

  • Upgrade ZenHive mpp to version 0.12.0 or later to obtain the vendor‑issued fix.
  • If upgrade is not immediately possible, disable Tempo fee sponsorship by setting fee_payer = false, causing clients to pay their own gas and preventing the sponsor wallet from being committed.
  • When sponsorship must remain enabled, lower the max_total_fee and max_validity_window_seconds settings to reduce the exposure per concurrent request and limit how long uncounted transactions remain broadcastable.
  • Monitor the sponsor wallet for abnormal withdrawal activity and adjust withdrawal limits or hold periods as a temporary countermeasure.

Generated by OpenCVE AI on August 20, 2026 at 13:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 20 Aug 2026 02:15:00 +0000

Type Values Removed Values Added
First Time appeared Zenhive
Zenhive mpp
Vendors & Products Zenhive
Zenhive mpp

Wed, 19 Aug 2026 19:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Wed, 19 Aug 2026 17:30:00 +0000

Type Values Removed Values Added
Description Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty. MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period. This issue affects mpp: from 0.2.0 before 0.12.0.
Title Tempo fee sponsorship in mpp bounds each transaction but not aggregate exposure, allowing concurrent sponsor-wallet drain
First Time appeared Zenhive
Zenhive mpp
Weaknesses CWE-770
CPEs cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*
Vendors & Products Zenhive
Zenhive mpp
References
Metrics cvssV4_0

{'score': 8.3, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N'}


cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-08-19T18:47:04.542Z

Reserved: 2026-08-18T10:00:02.140Z

Link: CVE-2026-73541

cve-icon Vulnrichment

Updated: 2026-08-19T18:46:46.063Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-08-19T18:17:25.627

Modified: 2026-08-20T13:02:12.153

Link: CVE-2026-73541

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-20T13:30:17Z

Weaknesses
  • CWE-770

    Allocation of Resources Without Limits or Throttling