Apache Sling XSS EUVD-2026-85175

Exploitation requires a downstream application that actually uses the Apache Sling XSS library (versions before 2.4.12) to encode or filter untrusted input for web output; the attacker submits input that defeats the library's neutralization logic, and a victim must load the resulting page (user interaction required). Limiting factors: the flaw only manifests where the affected API path is invoked, XSS is client-side and needs a victim to render the payload, and applications that upgrade to 2.4.12 or do not use the affected filtering path are not exposed. The exact vulnerable API and whether the payload persists (stored) or is reflected are not specified in the advisory.

This is a reflected/stored cross-site scripting flaw (CWE-79) in the Apache Sling XSS protection library itself - the very component applications call to neutralize untrusted input - so a bypass here silently re-exposes every consuming application to XSS. No CVSS score or vector is provided by Apache or NVD, no EPSS probability is published, the CVE is not in CISA KEV, and no public proof-of-concept is referenced; therefore there is no public exploit identified at time of analysis and no evidence of active exploitation. Priority is moderate rather than urgent: XSS is inherently client-side and requires victim interaction, but because this is a security library used as a control, the real impact is amplified - a filter bypass can affect many downstream apps at once. Key data is MISSING and must be treated with caution: the exact injection vector (which encoding/filtering API is affected), whether the flaw is reflected vs. stored, and affected downstream configurations are not detailed in the advisory. The single reference is an Apache mailing-list thread; affected-version data ('before 2.4.12') is confirmed by Apache but no independent CVSS or exploitability signal exists.

An attacker crafts input containing markup that bypasses Apache Sling XSS's sanitization/encoding routines and submits it to an application that relies on the library to render user-controlled content safely. When a victim views the resulting page, the payload executes in their browser session, enabling session/cookie theft or actions in the victim's context. No public proof-of-concept is available, and successful exploitation depends on a downstream application actually using the affected API for output that reaches other users.