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

Description

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.

Scores

EPSS (exploitation in 30 days)

0.52% · top 55% of all CVEs (6 Nov 2026)

CISA SSVC

Exploitation: none · Automatable: no · Technical impact: partial

The list uses the assigner's score when there is one, then CISA's, then NVD's: Medium 6.3.

Weakness

• CWE-524 Use of Cache Containing Sensitive Information (opens in a new tab)All about CWE-524 and its CVEs

Affected products

• ZenHive · mpp

  • affected 0.1.0 – < 0.16.2

• ZenHive · mpp

  • affected 2d4d1d94aae7790ae0623063961adbeef171fa71 – < 2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b

What to do

Workaround: In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

References (5)

• GitHub Advisory (opens in a new tab)relatedvendor-advisory
• EEF CNA record for CVE-2026-89186 (opens in a new tab)related
• OSV record EEF-CVE-2026-89186 (opens in a new tab)related
• Introducing commit 2d4d1d9 in ZenHive/mpp (opens in a new tab)related
• Fix commit 2fd91a5 in ZenHive/mpp (opens in a new tab)patch

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-89186](https://trackcve.app/badge/CVE-2026-89186.svg)](https://trackcve.app/cve/CVE-2026-89186)

Record last updated 16 Sept 2026, 14:50 UTC.