Intelligence
AEV-2026-0042

ZenHive mpp Tempo fee payer sponsor never checked the key authorization field it co signed (CVE-2026-82751)

The identical ZenHive mpp Tempo fee payer policy also never inspected an optional key_authorization field the same transaction envelope can carry. A signed key authorization causes the sponsor to pay the intrinsic gas and storage cost of provisioning a new access key, scoped by whatever limits the client attaches, on the client's own account. 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, roughly thirty nine times higher.

AESS 6.9 mediumReproducedStatus: resolvedEvent: 4 September 2026Approval ControlsExecution AuthorityDelegated Authority

Affected

Organisation
ZenHive
Product
mpp, an Elixir implementation of the Machine Payment Protocol, key authorization field omission
Component
MPP.Methods.Tempo.FeePayerPolicy.measure and validate, the Tempo fee payer sponsorship policy
Versions
from 0.2.0 before 0.16.1
Configurations
A server operating the Tempo fee payer sponsorship path, an opt in deployment choice a server must have enabled for the vulnerability to apply; A client signed 0x76 transaction envelope carrying an optional key_authorization field alongside the fields the policy does check

Execution authority facts

Fields the evidence does not establish are shown as unknown rather than guessed.

Intended task
A client submits a Tempo transaction for the server to sponsor, paying the client's own gas in exchange for the transaction meeting the server's fee payer policy
Agent
unknown
Delegating actor
unknown
Action
Attached a signed key_authorization field, one key plus three token spending limits in the reporter's own reproduction, to the client signed transaction the sponsor's policy evaluated and then co signed
Target resource
The client's own account, on which a new, scoped access key was persistently provisioned, and the sponsor's own gas budget
Environment
A server deployment of mpp with Tempo fee payer sponsorship enabled
Credentials used
unknown
Privileges available
Ordinary client side privileges sufficient to construct and sign a Tempo transaction
Authority presented
The sponsor's own policy decision that the transaction's gas, fee, validity window and access list fell inside its configured bounds
Authority required
A distinct, applicable grant covering whether the sponsor's co signature may also fund and authorize provisioning a new access key on the client's account, separate from the grant covering the payment itself
Applicable policy
MPP.Methods.Tempo.FeePayerPolicy.measure and validate, which the reporter's own advisory and this record's own direct read of the fix commit confirm evaluated gas, fee, validity and access list but not the key_authorization field before the fix
Approval mechanism
Automated policy check, not human review
Required approver
unknown
Independent approval
no
Action binding
The sponsor's own co signature covers the complete, unmutated transaction it signs, including the key_authorization field, whether or not its own policy evaluated that field
Sequence context
Policy evaluation and co signing occurred in one automated step, with no re-evaluation of the key authorization field at any later point before broadcast

Impact

Consequence
material
Reach
single
Reversibility
unknown
Detectability
unknown
Propagation
potential
Recovery
Not established by anything available to this record. Whether the provisioned access key can be revoked after the fact, and what it may already have authorized before any revocation, is not addressed by either advisory.

Evidence

Primary sources

Supporting sources

Reproduction status
Reported by the advisory's own author, kai-kka, as a reproduced gas cost measurement at one key authorization plus three token spending limits. This session independently fetched the GHSA advisory directly and independently fetched and read the fix commit directly, confirming the mechanism and the added checks, but did not itself reproduce the gas figures against a running mpp instance.
Evidence state
Reproduced

Known unknowns

  • Whether either vulnerability has been exploited outside the reporter's own disclosed reproduction. Nothing available to this record states active exploitation.
  • The exact scope, expiry and allowed calls a provisioned key can carry beyond the reporter's own reproduced example of three token spending limits.
  • The exact CWE assignment on the formal CVE record: the GHSA advisory itself states CWE-20, while independently corroborated search results attribute CWE-1284 to the CVE record specifically.
  • Whether the client's account, once a key is provisioned this way, retains any record distinguishing a sponsor authorized key from one funded through this gap.

Limitations

  • Direct fetch of the GHSA advisory and of the fix commit succeeded in this session; direct fetch of cve.org, nvd.nist.gov and several third party CVE aggregators did not, so the CVSS score, the CVE identifier's formal metadata and the exact CWE assignment rest on independently corroborated search results rather than a direct read of the CVE Program's own record.

Claim provenance