Apache Cocoon CVE-2026-108088

Requires an Apache Cocoon deployment that (1) has the Cocoon caching mechanism enabled and (2) serves multiple distinct users from the same instance, such that user-specific sensitive output is stored in a shared cache key reused across users. Exploitation is LIMITED by its opportunistic nature - the attacker cannot deterministically force a chosen victim's data into the cache - and by the requirement that the application actually cache sensitive, per-user content; single-user or cache-disabled deployments are not affected. No vendor patch exists (product retired); the only mitigations are migrating off Cocoon or restricting the instance to trusted users.

Signals here are sparse: no CVSS score or vector was published (N/A), no EPSS probability is provided, the CVE is not listed in CISA KEV, and no public exploit code is referenced - the only source is the Apache advisory thread. Based on CWE-524 (Use of Cache Containing Sensitive Information) and the description, this is an information-disclosure flaw where a shared cache in a multi-user Cocoon application can serve one user's cached content to another. Real-world risk is tempered strongly by context: Apache Cocoon is a RETIRED project with no deployment growth and a shrinking installed base, exploitation is opportunistic rather than attacker-controlled (an attacker cannot reliably force a specific victim's sensitive data into the cache they then receive), and it is gated on the application actually enabling caching in a multi-user deployment. With no exploitation-probability data, KEV entry, or POC, this reads as a low-urgency, condition-dependent issue rather than a widespread priority - the primary concern is that no fix will ever ship. KEY DATA MISSING: vendor assigned no CVSS, so attack vector, complexity, and privilege requirements are not confirmed by the source and are inferred here from the description only; authentication requirements are therefore not confirmed from available data.

In a multi-user Apache Cocoon application with caching enabled, one user requests a page whose sensitive, user-specific output is stored in a shared cache; a second user subsequently requesting the same resource is served the first user's cached content, disclosing the sensitive data. No public exploit code is identified, and the leak is opportunistic - the attacker cannot control which victim's data is cached and returned.