ZenHive MPP CVE-2026-89186

Exploitation requires all of the following, none of which are the library's default: (1) a mounting application that sets its own Cache-Control on the MPP-gated paid resource with a shareable directive (e.g. public, max-age=3600), overriding the library's Cache-Control: private via Plug.Conn.put_resp_header/3; and (2) a shared HTTP cache - a CDN or reverse proxy - in the response path that will store and replay the paid 200 along with its Payment-Receipt header. A related weaker condition needs no cache: because no register_before_send/2 callback strips it, a downstream non-2xx response still carries a Payment-Receipt, issuing a receipt for a response that delivered no resource. Limiting factors: the library's own default (Cache-Control: private on success, no-store on 402) is safe, so the vulnerable state only exists when the protected application misconfigures caching; without a shared cache the primary leak does not occur.

This is a genuine but modest-severity flaw whose real-world risk is tightly bounded by preconditions. The vendor CVSS 4.0 vector (6.3, AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L) already signals limited impact: only low confidentiality to the vulnerable system and to a subsequent system (the shared cache), with no integrity or availability effect. Critically, the vector carries AT:P (attack requirements present), which correctly captures that exploitation is not universal against defaults - it depends on a mounting application overriding the library's Cache-Control: private with a cacheable directive AND a CDN/reverse proxy being present in the response path. No EPSS score, KEV listing, or public POC was provided; per the precision rules this is 'no public exploit identified at time of analysis.' There is no SSVC decision data supplied. Note a nuance: the CVSS marks AC:L, but the description makes clear a specific application-side misconfiguration is required, so real-world attack complexity is higher than AC:L implies - the network vector is low-complexity to send, but the vulnerable state must first be created by the deploying app. Net: a real correctness/logic weakness worth patching, not an urgent widely-exploitable priority.

A developer mounts MPP.Plug to gate a premium API endpoint, and the endpoint's own controller (or an upstream layer) sets Cache-Control: public, max-age=3600 on the paid 200 response, silently overwriting the library's private directive. A CDN or reverse proxy in front of the app then stores that paid response together with its Payment-Receipt header and serves it verbatim to subsequent clients who never paid. No public exploit code is identified; the 'attack' is simply an unpaid client requesting the same cached URL.