MPP.Plug.injects a Payment‑Receipt header and a Cache‑Control: private directive before the wrapped application runs. If the downstream application later writes its own Cache‑Control header (e.g., public, max‑age=3600), the Plug’s private header is silently replaced, and the plug’s Payment‑Receipt header remains. A shared HTTP cache or CDN can then store the paid 200 response and the receipt, subsequently serving it to clients that never paid, exposing confidential payment information and content. In addition, non‑2xx responses can still carry the receipt, inadvertently communicating a successful purchase for failed requests.

The vulnerability exists in ZenHive’s MPP plug for all releases from 0.1.0 up to but not including 0.16.2. This includes any project that mounts MPP.Plug in front of a protected application.

The CVSS score of 6.3 indicates a moderate risk. EPSS data is unavailable and the CVE is not listed in CISA’s KEV catalog, suggesting no widely used exploit is known. The likely attack vector is configuration or request manipulation: an attacker who can trigger a paid response or cause the application to set a public Cache‑Control header could lead a shared cache to store and redistribute that response. The exploit does not require code execution or privileged access, merely the ability to request or influence the paid resource’s caching policy.