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.
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


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.

History

Wed, 16 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Wed, 16 Sep 2026 14:00:00 +0000

Type Values Removed Values Added
First Time appeared Zenhive
Zenhive mpp
Vendors & Products Zenhive
Zenhive mpp

Wed, 16 Sep 2026 08:30:00 +0000

Type Values Removed Values Added
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.
Title 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
First Time appeared Zenhive
Zenhive mpp
Weaknesses CWE-524
CPEs cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*
Vendors & Products Zenhive
Zenhive mpp
References
Metrics cvssV4_0

{'score': 6.3, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N'}


Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-09-16T14:50:44.399Z

Reserved: 2026-09-11T19:00:02.549Z

Link: CVE-2026-89186

cve-icon Vulnrichment

Updated: 2026-09-16T14:50:40.806Z

cve-icon NVD

Status : Received

Published: 2026-09-16T09:17:07.527

Modified: 2026-09-16T15:18:06.193

Link: CVE-2026-89186

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-16T14:15:09Z

Weaknesses