CVE-2026-89186 in mpp
Summary
by MITRE • 09/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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in ZenHive's MPP library represents a critical failure in access control enforcement due to improper cache management and header handling within the HTTP request-response cycle. This flaw allows an attacker or any client without valid credentials to retrieve content that should be restricted to paying users by exploiting how intermediate caching mechanisms interact with application-level security headers. The core issue stems from the interaction between the library's attempt to enforce privacy for paid resources and the behavior of downstream proxies, CDNs, and the mounting applications themselves which may override these directives.
At a technical level, the MPP.Plug.verify_credential function is designed to secure responses by setting specific HTTP headers on the connection object before passing control to the wrapped application. Specifically, it attempts to set the Cache-Control header to private and includes a Payment-Receipt header to indicate that payment has been verified for this response. However, the implementation relies on Plug.Conn.put_resp_header/3 which replaces any existing value for a given header key rather than appending or enforcing immutability. Consequently if the mounting application explicitly sets its own cache control directives such as public with a max-age directive these values silently overwrite the private directive set by the security library. This override effectively signals to intermediate caching devices that the response is safe to store and share publicly, directly contradicting the intended security policy of restricting access to authenticated or paying users only.
The operational impact of this vulnerability is severe as it leads to a complete bypass of paywall mechanisms. When an application sets cache control headers like public max-age=3600 on paid resources the intermediate CDN or reverse proxy stores the response including any sensitive data contained within and potentially the Payment-Receipt header itself. Subsequent requests from clients who have not paid for access can be served this cached content directly by the intermediary without ever reaching the application server where authentication checks would normally occur. This results in unauthorized access to premium features, copyrighted material, or restricted API endpoints effectively allowing free consumption of services that require payment. Furthermore because non-successful responses such as errors may still carry the Payment-Receipt header due to similar header replacement logic there is also a risk of information leakage regarding which resources were previously accessed by paying users although this is secondary to the primary access control failure.
This vulnerability aligns with CWE-524 Use of Cache Containing Sensitive Information and CWE-16 Configuration as it involves misconfiguration or improper handling of security-critical HTTP headers that dictate caching behavior. In terms of attack patterns it relates to ATT&CK technique T1078 Valid Accounts where an attacker leverages valid credentials once obtained or exploits the system's trust in cached responses to gain unauthorized access without needing persistent authentication tokens for each request. The flaw is particularly dangerous because it does not require complex exploitation techniques but rather relies on standard web application behaviors that developers might inadvertently introduce when configuring their own caching strategies.
Mitigation requires a multi-layered approach focusing on both the library implementation and the consuming applications. For users of the MPP library upgrading to version 0.16.2 or later is essential as this release addresses the header handling logic to prevent unauthorized overwriting of security directives. Developers must ensure that no downstream application code overrides cache control headers for protected resources using standard put_resp_header functions which allow replacement. Instead applications should utilize mechanisms that enforce immutability or append-only behaviors where supported by the web framework. Additionally it is crucial to configure CDNs and reverse proxies with explicit caching rules that respect private directives regardless of any conflicting public settings from upstream sources ensuring that responses marked as private are never cached at intermediate nodes. Regular security audits focusing on header manipulation vulnerabilities should also be conducted to identify similar patterns in other parts of the application stack where sensitive data might be inadvertently exposed through improper cache management practices.