The Sponsor Approved the Payment Budget. The Same Signature Paid for a New Delegation and Access Key.

A fee payer sponsorship arrangement exists so a client does not need its own funded account to transact. A server, the sponsor, agrees in advance to pay the gas for transactions that meet its own policy, then co signs and broadcasts whatever the client submits, provided that policy passes. The idea only works if the policy actually bounds what the sponsor ends up paying for and, more importantly, what the sponsor's own signature ends up authorizing. Two vulnerabilities disclosed against ZenHive's mpp, an Elixir implementation of the Machine Payment Protocol built for AI agent and machine to machine commerce, show a policy that bounded the payment and left the authorization unbounded.

One policy, two fields it never read

Both vulnerabilities sit in the same function pair, MPP.Methods.Tempo.FeePayerPolicy.measure and validate, which a server calls when it sponsors a Tempo transaction. Both advisories agree on what that policy does check: the transaction's gas limit, capped at 2,000,000 by the reporter's own description; its maximum fee per gas, capped at 100 Gwei; an expiring nonce and a bounded validity window; and an access list the policy requires to be empty. What it does not check is where the two disclosures diverge, and each names a different field in the same signed transaction envelope.

GHSA 5qrp r24c w6jr, published 4 September 2026 and assigned CVE 2026 82750, states that the policy never reads the transaction's EIP 7702 authorization list, described in independently corroborated technical accounts of the advisory under the field name tempo_authorization_list, while a separate independently corroborated account of the underlying CVE record describes the same field as aa_authorization_list. This record states both names rather than resolving the discrepancy, since it could not independently read either the advisory's own source text or the CVE record directly to settle which name is current, historical or specific to one description of the same field. Whichever name is correct, the mechanism is the same: EIP 7702 lets an Ethereum style account attach signed authorizations delegating its own code to a smart contract, a persistent change to what the account is, not a one time instruction. Every entry in the list is charged as fixed intrinsic gas before the sponsored payment call itself runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for each one. The reporter's own reproduction, at a default of seven entries, moved the transaction's cost from about 46,575 gas to about 1,884,087 gas, a multiplier the advisory states at roughly forty times, while remaining inside every bound the policy actually checks. The persistent effect, not the multiplier, is the part this record treats as the more important fact: each of those seven signed delegations survives the transaction and upgrades the client's own account to delegated, smart contract style code, funded entirely by a sponsor whose policy never asked whether any delegation was present at all.

GHSA rpwj vrf7 4x36, published the same day and assigned CVE 2026 82751, names a second, independent gap in the identical policy: an optional key_authorization field the transaction envelope can carry, which the policy also never inspects. A client attaching a signed key authorization causes the sponsor to pay the intrinsic gas and storage cost of provisioning a new access key on the client's own account, again while staying inside every field the policy does check. The reporter's own reproduction, one key plus three token spending limits, moved the cost from about 46,587 gas to about 1,808,700 gas, a multiplier the advisory states at roughly thirty nine times. The persistent effect here is a live, scoped access key the client acquired at no cost to itself, an access key that, subject to whatever limits were attached to it, may authorize further transactions on the client's account after this one settles.

Why this is not a gas accounting bug

It would be easy to read both advisories as instances of one underlying complaint, a fee payer that does not bound its own costs tightly enough, and mpp's own disclosure history gives that reading some surface plausibility: the same repository has published several earlier advisories about gas draining specifically, including one from 2 August 2026 addressing aggregate exposure across concurrent sponsored requests, a related but distinct issue this record does not fold into either CVE here. Reading these two disclosures the same way would miss what actually failed. The reported cost multipliers, roughly forty times and roughly thirty nine times, are a consequence of the failure, not its substance. A policy that bounded gas more tightly, say by capping the number of authorization list entries or key authorizations rather than by ignoring the fields outright, would still face the same underlying question: once any such entry is permitted at all, has anyone decided that the sponsor's payment authority extends to funding it, distinct from the sponsor's decision to fund the payment itself. The advisories' own reported fix answers that question by rejecting the fields outright, or by requiring a sponsor to name an exact authorization it expects in advance, not by raising a limit.

Budget authority is not effect authority

Moona Intelligence's own reading of both disclosures rests on a distinction the fee payer policy's own design silently erased. A fee payer sponsor holds financial sponsorship authority, the authority to decide which payments it will fund and up to what cost. It does not automatically hold delegation authority, the authority to decide whether a client's account may be upgraded to delegated code, or credential provisioning authority, the authority to decide whether a new access key may be provisioned on a client's account. Those are three separate capabilities, and a single co signature covering a single transaction envelope does not keep them separate on its own. Once a transaction format allows more than one effect bearing field inside one signed object, a policy that evaluates only the fields it was originally written to check is not thereby limiting what its own signature authorizes. It is only limiting what it noticed.

Both fixes, read against the same source this record independently reviewed, close the gap the same way rather than by tightening a limit. The merged commit, 0482572b47e1ffe1537ab80ab613d47b92833c2d, adds a check_authorization_list function that rejects any non empty EIP 7702 authorization list for a sponsored transaction outright and fails closed on a malformed authorization list representation, so an unparseable field blocks the transaction rather than passing silently. It adds a matching check_key_authorization function that rejects a key authorization by default, and adds a policy level expected_key_authorization field a sponsor may explicitly pin, in which case the function compares the transaction's own key authorization against that pinned value byte for byte rather than merely checking that some value is present. Both checks run inside the same validate path that produces the sponsor's co signature, and the repository's own added tests assert that measure, which estimates the sponsored cost, and validate, which decides whether to sign, apply the identical field level policy rather than one checking more than the other. The corrective, in other words, is not a lower gas ceiling. It is making every field the co signature will cover a field the policy actually decided about, either by refusing it outright or by binding it to an exact, independently verified value.

The Authority Provenance ledger

Client principal. Whoever constructed and signed the client side of the sponsored transaction, including its EIP 7702 authorization list or key_authorization field where either is present. Unnamed in either advisory; mpp's own stated purpose is HTTP 402 payment middleware for AI agents and machine to machine commerce, so this record treats the client as potentially an autonomous agent without asserting that every reported reproduction was one.

Sponsor principal. The server operating MPP.Methods.Tempo.FeePayerPolicy under a Tempo fee payer sponsorship configuration, an opt in deployment choice a server must have enabled for either vulnerability to apply. A deployment that does not sponsor Tempo payments does not run this policy path at all.

Transaction identity. The specific, client signed 0x76 envelope the sponsor co signs and broadcasts, carrying gas, fee, validity, access list, and optionally an EIP 7702 authorization list and a key_authorization field, all inside one signed object.

Primary payment effect. The transfer or call the sponsor's policy was written to evaluate: whether the requested gas, fee, validity window and access list fall inside the sponsor's configured bounds.

Budget. The gas limit, maximum fee per gas and validity window the policy actually checks before co signing, unchanged by either vulnerability.

EIP 7702 authorization list. Before the fix, unchecked. Each signed entry persistently delegates the client's own account to smart contract style code and is charged to the sponsor as intrinsic gas, subject to CVE 2026 82750.

Key authorization. Before the fix, unchecked. A signed key_authorization field persistently provisions a new access key on the client's account, funded by the sponsor's intrinsic gas payment, subject to CVE 2026 82751.

Signature. The sponsor's own co signature, which legally covers the complete transaction object it signs and broadcasts, including the authorization list and key authorization fields, whether or not its own policy evaluated either one.

Persistent effect. A delegated account, or a live access key with whatever scope was attached to it, both of which continue to exist and to be usable after the sponsored payment itself has settled, independent of anything the payment's own budget check evaluated.

What remains unknown

Neither advisory, on the material this record could independently verify, states that either vulnerability has been actively exploited, and this record does not claim otherwise. Neither states that every mpp deployment is affected regardless of configuration: fee payer sponsorship of Tempo payments is an opt in choice a server must enable. This record could not independently verify, from a primary CVE Program or NVD record directly, every metadata field search aggregated reporting attributes to the formal CVE entries, including a CWE 1284 classification distinct from the CWE 20 classification the GHSA advisories themselves state, and records both rather than resolving the discrepancy. Whether mpp's maintainers have published any narrowing advisory after 4 September 2026 addressing either mechanism specifically was not found by this record as of publication. Version 0.16.1, independently confirmed as mpp's current published release, is treated here as the current fixed version for both CVEs absent evidence of a later regression or narrowing advisory.

Where this sits next to what Moona Intelligence has already written

This is not the same failure this desk has already documented in agent payment authorization evidence, where the open question was whether a payment's own authorization decision could be evidenced afterward. Here the authorization decision itself was incomplete: two fields with independent, persistent authority consequences sat inside the same signed object as the payment and were never evaluated at all. It is closer in shape to this desk's reading of authority propagating across a chain of agents, in that both concern how far one authorization decision actually reaches once a system boundary or a compound object is involved, though propagation across agents and completeness within one signed transaction are distinct mechanisms this record keeps separate rather than merging.