ZenHive mpp CVE-2026-73829

Exploitation requires that a non-nil dedup store be explicitly configured in the mpp deployment - the default nil store is stateless and documented as offering no replay protection, so deployments using the default are unaffected by this specific race (though they already lack any replay defense). The vulnerability is confined to the type='hash' credential path; the type='transaction' path uses the atomic check_and_mark/2 primitive and is not vulnerable. The exploitable race window is as wide as the eth_getTransactionReceipt RPC latency - longer blockchain RPC latency makes exploitation easier. No authentication is required (PR:N per CVSS 4.0 vector). The attacker must possess or be able to observe a valid settled payment hash, which implies either a prior legitimate payment or a hash obtained from transaction monitoring. Exploitation is constrained to mpp versions 0.2.0 through 0.6.0.

The CVSS 4.0 score of 6.3 is reasonable for the raw mechanics, but the financial impact on services using mpp for payment gating likely exceeds what the VI:L rating conveys - a single payment can unlock arbitrarily many resource grants depending on how quickly an attacker can saturate the race window. AT:P in the CVSS 4.0 vector correctly captures that a dedup store must be configured; the default nil store is stateless and provides no replay protection of any kind (documented), so nil-store deployments are unaffected by this specific race though they are already unprotected. AC:L in CVSS 4.0 reflects that once the configuration condition is met, the timing window is passively wide (bounded by RPC latency) rather than requiring precise millisecond manipulation. No CISA KEV listing exists and no public POC has been identified, so exploitation probability is inferred from description mechanics rather than observed attacks. EPSS data was not supplied in the input. The attack is mechanically straightforward - no authentication, no special tooling, no non-default OS configuration beyond the configured store - making the real-world risk higher than a 6.3 score may suggest for services whose revenue model depends on payment integrity.

An attacker identifies a service running mpp 0.2.0-0.6.0 with a configured dedup store and obtains or observes a valid confirmed on-chain payment hash (e.g., by making a legitimate small payment). The attacker then fans out two or more concurrent HTTP requests to the Tempo verification endpoint carrying the same hash; all requests pass check_hash_unused/2 before the on-chain RPC completes for any of them, each independently verifies the payment on-chain, and each receives a valid resource-access receipt - granting multiple accesses for the cost of one payment. No authentication, elevated privileges, or specialized tooling beyond a concurrent HTTP client are required.