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. Additionally, non‑2xx responses may still carry the receipt, accidentally communicating a 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. The EPSS score of 0.00394 (approximately <1%) indicates a very low yet non‑zero likelihood of exploitation. The CVE is not listed in CISA’s KEV catalog, suggesting no widely known exploit. 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.