6
CVEs
0
Critical
5
High
0
KEV
2
PoC
0
Unpatched C/H
100.0%
Patch Rate
0.4%
Avg EPSS
Severity Breakdown
CRITICAL
0
HIGH
5
MEDIUM
1
LOW
0
Monthly CVE Trend
Affected Products (1)
Top Risky CVEs
| CVE | Summary | Severity | CVSS | EPSS | Priority | Signals |
|---|---|---|---|---|---|---|
| CVE-2026-82750 | Missing validation of the EIP-7702 aa_authorization_list field in ZenHive mpp's Tempo payment sponsorship module allows any unauthenticated remote client to inflate the fee-payer's gas cost by roughly 40x and to have the sponsor pay for persistent EIP-7702 set-code delegations on attacker-controlled Ethereum accounts. Versions 0.2.0 through 0.16.0 are affected; the FeePayerPolicy.measure/3 function validates gas fields, fee budget, validity window, and access list but never inspects the aa_authorization_list, so a client embedding seven throwaway delegation entries drives sponsored gas from approximately 46,575 to over 1,884,087. No public exploit has been identified at time of analysis, and a vendor patch is available in mpp 0.16.1. | HIGH | 8.3 | 0.3% | 62 |
PoC
|
| CVE-2026-82751 | Gas-cost inflation and unauthorized access key provisioning in ZenHive mpp (versions 0.2.0 through 0.15.x) allows any unauthenticated remote client to attach a fully signed key_authorization payload to a Tempo 0x76 payment envelope, forcing the fee sponsor to pay for persistent blockchain storage writes the client itself initiated. At the reporter's default test case of one access key with three token spending limits, the sponsor's gas cost rises from roughly 46,587 to roughly 1,808,700 gas - approximately a 39x multiplier - while the client retains a valid access key it paid nothing for. No public exploit has been identified at time of analysis, but the vulnerability is well-specified and trivially reproducible given knowledge of the Tempo protocol. | HIGH | 8.3 | 0.3% | 62 |
PoC
|
| CVE-2026-67581 | Replay of settled EVM blockchain transaction hashes against ZenHive mpp versions 0.3.0-0.6.2 allows unauthenticated remote attackers to obtain paid resources at no cost. MPP.Methods.EVM.verify/2 validates payment by matching a submitted transaction hash against on-chain token/recipient/amount fields but neither binds the proof to a specific challenge nor records prior use; because MPP.Plug regenerates challenge.id on every 402 response, any historical on-chain transfer visible on a public block explorer can satisfy an unlimited number of subsequent payment challenges on a static-price route. No public exploit code has been identified at time of analysis and no CISA KEV listing exists, though the attack prerequisites are trivially met given the public nature of blockchain transaction data. | HIGH | 8.7 | 0.5% | 44 |
|
| CVE-2026-73541 | Concurrent sponsored-payment flooding in ZenHive mpp (versions 0.2.0 through 0.12.0) allows an unauthenticated remote client to drain a fee-payer wallet to zero, denying service to all legitimate sponsored-transaction users once the wallet is empty. The root cause is that MPP.Methods.Tempo.FeePayerPolicy enforces per-transaction budget ceilings but maintains no aggregate accounting across concurrent in-flight sponsorships, meaning N simultaneous sponsored requests commit N × max_total_fee against the wallet with no global cap. No public exploit has been identified at time of analysis, but the attack is mechanically trivial once the sponsor endpoint is reachable - no authentication, no cryptographic preconditions, only the ability to issue distinct signed transactions with distinct nonces within the 900-second validity window. | HIGH | 8.3 | 0.4% | 42 |
|
| CVE-2026-73136 | Capture-replay authentication bypass in ZenHive mpp versions 0.6.1-0.6.3 allows unauthenticated network attackers to claim paid resources by reusing a legitimate customer's public TIP-20 TransferWithMemo transaction hash. When the Tempo payment method is configured with a static 'memo' value in method_config, the per-challenge attribution nonce binding that ties a specific transfer to a specific verification challenge is skipped unconditionally, and the hash credential path performs no sender or wallet-signature check - leaving only token, recipient, amount, and the static memo (itself broadcast in every unauthenticated 402 response) to match. No active exploitation is confirmed and no public exploit code has been identified; a vendor patch is available in mpp 0.6.4. | HIGH | 8.2 | 0.5% | 42 |
|
| CVE-2026-73829 | Payment-replay protection in ZenHive mpp's Tempo hash-credential path is defeated by a TOCTOU race condition, allowing a single confirmed on-chain payment hash to be redeemed for multiple paid-resource grants. The race window spans an eth_getTransactionReceipt RPC round trip - potentially hundreds of milliseconds - during which concurrent unauthenticated requests all pass the non-atomic read guard before any write completes. Affected deployments run mpp 0.2.0 through 0.6.0 with a dedup store configured; no public exploit has been identified at time of analysis, but the attack requires only a standard concurrent HTTP client and knowledge of a valid settled payment hash. | MEDIUM | 6.3 | 0.2% | 32 |
|