Answer in brief
CVE-2026-89186 records a Unknown severity vulnerability in mpp writes Payment-Receipt and Cache-Control before the wrapped application runs, letting a consumer's own Cache-Control expose paid responses to shared caches. The current sources do not mark it as known exploited. The current feed maps ZenHive/mpp (generic), ZenHive/mpp (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps ZenHive/mpp (generic), ZenHive/mpp (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| ZenHive/mppgeneric | >=0.1.0 <0.16.2 | 0.16.2 |
| ZenHive/mppgeneric | >=2d4d1d94aae7790ae0623063961adbeef171fa71 <2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b | 2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b |
Published upstream
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 16, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 16, 2026
Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid. MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource. This issue affects mpp: from 0.1.0 before 0.16.2.
Quoted source text, attributed separately from HOL analysis.