CVE-2026-89186 (GCVE-0-2026-89186)
Vulnerability from cvelistv5 – Published: 2026-09-16 08:24 – Updated: 2026-09-16 14:50
VLAI
EPSS
VEX
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
Summary
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.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-09-16 14:50 UTC
CWE
- CWE-524 - Use of Cache Containing Sensitive Information
Assigner
References
5 references
| URL | Tags |
|---|---|
| https://github.com/ZenHive/mpp/security/advisorie… | relatedvendor-advisory |
| https://cna.erlef.org/cves/CVE-2026-89186.html | related |
| https://osv.dev/vulnerability/EEF-CVE-2026-89186 | related |
| https://github.com/ZenHive/mpp/commit/2d4d1d94aae… | related |
| https://github.com/ZenHive/mpp/commit/2fd91a5ecbd… | patch |
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-89186",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-16T14:50:34.541725Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-16T14:50:44.399Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Plug\u0027"
],
"packageName": "mpp",
"packageURL": "pkg:hex/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Plug\u0027:call/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "0.16.2",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Plug\u0027"
],
"packageName": "zenhive/mpp",
"packageURL": "pkg:github/zenhive/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Plug\u0027:call/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b",
"status": "affected",
"version": "2d4d1d94aae7790ae0623063961adbeef171fa71",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReachable only where the application mounted behind \u003ccode\u003eMPP.Plug\u003c/code\u003e sets its own \u003ccode\u003eCache-Control\u003c/code\u003e on the paid resource, overriding the \u003ccode\u003eprivate\u003c/code\u003e the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no \u003ccode\u003eCache-Control\u003c/code\u003e of its own keeps the library\u0027s \u003ccode\u003eprivate\u003c/code\u003e and is not affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reachable only where the application mounted behind `MPP.Plug` sets its own `Cache-Control` on the paid resource, overriding the `private` the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no `Cache-Control` of its own keeps the library\u0027s `private` and is not affected."
}
],
"value": "Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library\u0027s private and is not affected."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.16.2",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "E.FU"
},
{
"lang": "en",
"type": "remediation developer",
"value": "E.FU"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-15T15:22:44.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse 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.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eMPP.Plug.verify_credential\u003c/code\u003e in \u003ccode\u003elib/mpp/plug.ex\u003c/code\u003e sets \u003ccode\u003epayment-receipt\u003c/code\u003e and \u003ccode\u003ecache-control: private\u003c/code\u003e on the connection before the wrapped application runs, and registers no \u003ccode\u003eregister_before_send/2\u003c/code\u003e callback. \u003ccode\u003ePlug.Conn.put_resp_header/3\u003c/code\u003e replaces an existing header, so a mounting application that sets its own \u003ccode\u003ecache-control\u003c/code\u003e on the paid resource (for example \u003ccode\u003epublic, max-age=3600\u003c/code\u003e) silently overrides the \u003ccode\u003eprivate\u003c/code\u003e the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its \u003ccode\u003ePayment-Receipt\u003c/code\u003e 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 \u003ccode\u003ePayment-Receipt\u003c/code\u003e, issuing a receipt for a response that delivered no resource.\u003c/p\u003e\n\u003cp\u003eThis issue affects mpp: from 0.1.0 before 0.16.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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.\n\n`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.\n\nThis issue affects mpp: from 0.1.0 before 0.16.2."
}
],
"value": "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.\n\nMPP.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.\n\nThis issue affects mpp: from 0.1.0 before 0.16.2."
}
],
"impacts": [
{
"capecId": "CAPEC-204",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn unpaid client requesting the same URL through the shared cache receives the cached paid response, including the \u003ccode\u003ePayment-Receipt\u003c/code\u003e header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the `Payment-Receipt` header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties."
}
],
"value": "An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-524",
"description": "CWE-524 Use of Cache Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-16T08:24:15.058Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-82qh-vrvm-gqvc"
},
{
"name": "EEF CNA record for CVE-2026-89186",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-89186.html"
},
{
"name": "OSV record EEF-CVE-2026-89186",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-89186"
},
{
"name": "Introducing commit 2d4d1d9 in ZenHive/mpp",
"tags": [
"related"
],
"url": "https://github.com/ZenHive/mpp/commit/2d4d1d94aae7790ae0623063961adbeef171fa71"
},
{
"name": "Fix commit 2fd91a5 in ZenHive/mpp",
"tags": [
"patch"
],
"url": "https://github.com/ZenHive/mpp/commit/2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "mpp writes Payment-Receipt and Cache-Control before the wrapped application runs, letting a consumer\u0027s own Cache-Control expose paid responses to shared caches",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn the application mounted behind \u003ccode\u003eMPP.Plug\u003c/code\u003e, stop setting \u003ccode\u003eCache-Control\u003c/code\u003e on paid routes so the library\u0027s \u003ccode\u003eprivate\u003c/code\u003e survives to the response, or set a directive that is itself safe for a shared cache (\u003ccode\u003eprivate\u003c/code\u003e, or \u003ccode\u003eno-store\u003c/code\u003e). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a \u003ccode\u003ePayment-Receipt\u003c/code\u003e header.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "In the application mounted behind `MPP.Plug`, stop setting `Cache-Control` on paid routes so the library\u0027s `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."
}
],
"value": "In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library\u0027s 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."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-89186",
"datePublished": "2026-09-16T08:24:15.058Z",
"dateReserved": "2026-09-11T19:00:02.549Z",
"dateUpdated": "2026-09-16T14:50:44.399Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-89186",
"date": "2026-11-08",
"epss": "0.00524",
"percentile": "0.44686"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Plug\u0027"
],
"packageName": "mpp",
"packageURL": "pkg:hex/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Plug\u0027:call/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "0.16.2",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Plug\u0027"
],
"packageName": "zenhive/mpp",
"packageURL": "pkg:github/zenhive/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Plug\u0027:call/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b",
"status": "affected",
"version": "2d4d1d94aae7790ae0623063961adbeef171fa71",
"versionType": "git"
}
]
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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.\n\nMPP.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.\n\nThis issue affects mpp: from 0.1.0 before 0.16.2."
}
],
"id": "CVE-2026-89186",
"lastModified": "2026-09-16T20:38:33.883",
"metrics": {
"cvssMetricV40": [
{
"cvssData": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"availabilityRequirement": "NOT_DEFINED",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"confidentialityRequirement": "NOT_DEFINED",
"exploitMaturity": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-89186",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-16T14:50:34.541725Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-09-16T09:17:07.527",
"references": [
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://cna.erlef.org/cves/CVE-2026-89186.html"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/ZenHive/mpp/commit/2d4d1d94aae7790ae0623063961adbeef171fa71"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/ZenHive/mpp/commit/2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-82qh-vrvm-gqvc"
},
{
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-89186"
}
],
"sourceIdentifier": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"vulnStatus": "Awaiting Analysis",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-524"
}
],
"source": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"type": "Secondary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-89186",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-09-16T14:50:34.541725Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-09-16T14:50:40.806Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.hex.pm",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Plug\u0027"
],
"packageName": "mpp",
"packageURL": "pkg:hex/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Plug\u0027:call/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "0.16.2",
"status": "affected",
"version": "0.1.0",
"versionType": "semver"
}
]
},
{
"collectionURL": "https://github.com",
"cpes": [
"cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*"
],
"defaultStatus": "unaffected",
"modules": [
"\u0027Elixir.MPP.Plug\u0027"
],
"packageName": "zenhive/mpp",
"packageURL": "pkg:github/zenhive/mpp",
"product": "mpp",
"programFiles": [
"lib/mpp/plug.ex"
],
"programRoutines": [
{
"name": "\u0027Elixir.MPP.Plug\u0027:call/2"
}
],
"repo": "https://github.com/ZenHive/mpp",
"vendor": "ZenHive",
"versions": [
{
"lessThan": "2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b",
"status": "affected",
"version": "2d4d1d94aae7790ae0623063961adbeef171fa71",
"versionType": "git"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eReachable only where the application mounted behind \u003ccode\u003eMPP.Plug\u003c/code\u003e sets its own \u003ccode\u003eCache-Control\u003c/code\u003e on the paid resource, overriding the \u003ccode\u003eprivate\u003c/code\u003e the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no \u003ccode\u003eCache-Control\u003c/code\u003e of its own keeps the library\u0027s \u003ccode\u003eprivate\u003c/code\u003e and is not affected.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "Reachable only where the application mounted behind `MPP.Plug` sets its own `Cache-Control` on the paid resource, overriding the `private` the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no `Cache-Control` of its own keeps the library\u0027s `private` and is not affected."
}
],
"value": "Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library\u0027s private and is not affected."
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*",
"versionEndExcluding": "0.16.2",
"versionStartIncluding": "0.1.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
],
"operator": "AND"
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "E.FU"
},
{
"lang": "en",
"type": "remediation developer",
"value": "E.FU"
},
{
"lang": "en",
"type": "coordinator",
"value": "Jonatan M\u00e4nnchen / EEF"
}
],
"dateAssigned": "2026-09-15T15:22:44.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUse 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.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eMPP.Plug.verify_credential\u003c/code\u003e in \u003ccode\u003elib/mpp/plug.ex\u003c/code\u003e sets \u003ccode\u003epayment-receipt\u003c/code\u003e and \u003ccode\u003ecache-control: private\u003c/code\u003e on the connection before the wrapped application runs, and registers no \u003ccode\u003eregister_before_send/2\u003c/code\u003e callback. \u003ccode\u003ePlug.Conn.put_resp_header/3\u003c/code\u003e replaces an existing header, so a mounting application that sets its own \u003ccode\u003ecache-control\u003c/code\u003e on the paid resource (for example \u003ccode\u003epublic, max-age=3600\u003c/code\u003e) silently overrides the \u003ccode\u003eprivate\u003c/code\u003e the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its \u003ccode\u003ePayment-Receipt\u003c/code\u003e 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 \u003ccode\u003ePayment-Receipt\u003c/code\u003e, issuing a receipt for a response that delivered no resource.\u003c/p\u003e\n\u003cp\u003eThis issue affects mpp: from 0.1.0 before 0.16.2.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "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.\n\n`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.\n\nThis issue affects mpp: from 0.1.0 before 0.16.2."
}
],
"value": "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.\n\nMPP.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.\n\nThis issue affects mpp: from 0.1.0 before 0.16.2."
}
],
"impacts": [
{
"capecId": "CAPEC-204",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAn unpaid client requesting the same URL through the shared cache receives the cached paid response, including the \u003ccode\u003ePayment-Receipt\u003c/code\u003e header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the `Payment-Receipt` header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties."
}
],
"value": "An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties."
}
]
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 6.3,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "LOW",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-524",
"description": "CWE-524 Use of Cache Containing Sensitive Information",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-16T08:24:15.058Z",
"orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"shortName": "EEF"
},
"references": [
{
"name": "GitHub Advisory",
"tags": [
"related",
"vendor-advisory"
],
"url": "https://github.com/ZenHive/mpp/security/advisories/GHSA-82qh-vrvm-gqvc"
},
{
"name": "EEF CNA record for CVE-2026-89186",
"tags": [
"related"
],
"url": "https://cna.erlef.org/cves/CVE-2026-89186.html"
},
{
"name": "OSV record EEF-CVE-2026-89186",
"tags": [
"related"
],
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-89186"
},
{
"name": "Introducing commit 2d4d1d9 in ZenHive/mpp",
"tags": [
"related"
],
"url": "https://github.com/ZenHive/mpp/commit/2d4d1d94aae7790ae0623063961adbeef171fa71"
},
{
"name": "Fix commit 2fd91a5 in ZenHive/mpp",
"tags": [
"patch"
],
"url": "https://github.com/ZenHive/mpp/commit/2fd91a5ecbd0b0ad2a4ac202b79659e8126dbc0b"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "mpp writes Payment-Receipt and Cache-Control before the wrapped application runs, letting a consumer\u0027s own Cache-Control expose paid responses to shared caches",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn the application mounted behind \u003ccode\u003eMPP.Plug\u003c/code\u003e, stop setting \u003ccode\u003eCache-Control\u003c/code\u003e on paid routes so the library\u0027s \u003ccode\u003eprivate\u003c/code\u003e survives to the response, or set a directive that is itself safe for a shared cache (\u003ccode\u003eprivate\u003c/code\u003e, or \u003ccode\u003eno-store\u003c/code\u003e). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a \u003ccode\u003ePayment-Receipt\u003c/code\u003e header.\u003c/p\u003e"
},
{
"base64": false,
"type": "text/markdown",
"value": "In the application mounted behind `MPP.Plug`, stop setting `Cache-Control` on paid routes so the library\u0027s `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."
}
],
"value": "In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library\u0027s 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."
}
]
}
},
"cveMetadata": {
"assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
"assignerShortName": "EEF",
"cveId": "CVE-2026-89186",
"datePublished": "2026-09-16T08:24:15.058Z",
"dateReserved": "2026-09-11T19:00:02.549Z",
"dateUpdated": "2026-09-16T14:50:44.399Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.