Adobe Experience Manager CVE-2025-64590

Requires a low-privileged authenticated account (PR:L) on the AEM instance with the ability to submit data into one of the vulnerable form fields, plus a victim who subsequently browses the page that renders the stored field (UI:R) - reflecting a persistent/stored XSS in AEM's form-handling components. Limiting factors: exploitation is not possible pre-authentication, depends on another user viewing the affected content, and impact is bounded to the victim's browser session (Low C/I, no availability impact). Highest realistic exposure is in multi-author, multi-tenant, or externally-facing content-submission deployments of AEM 6.5.23 and earlier (including 6.5 LTS) and affected AEM Cloud Service versions.

This is a genuinely moderate-severity, low-priority issue rather than a top-tier threat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, score 5.4) describes a network-reachable but authenticated (PR:L) stored XSS requiring victim interaction (UI:R), with only Low confidentiality and integrity impact and no availability impact - the scope change (S:C) reflects script execution crossing into the victim's browser security context. Real-world exploitation signals are weak and mutually consistent: EPSS is just 0.25% (15th percentile), there is no CISA KEV listing, and no public proof-of-concept was identified. All signals align - low CVSS, low EPSS, no active exploitation - so there is no conflict suggesting hidden risk. The main gating factor is that the attacker must already hold a low-privileged authenticated account on the AEM instance and must lure/await a victim viewing the affected page; this limits it to insider, multi-tenant, or post-authentication-compromise scenarios rather than mass internet exploitation. SSVC-style framing: exploitation=none observed, automatable=no (requires authenticated injection plus victim interaction), technical impact=partial. Prioritize behind unauthenticated or actively-exploited AEM flaws, but patch in normal cycle given AEM's exposure in content-publishing workflows.

A low-privileged authenticated user (e.g., a content author in a multi-author or multi-tenant AEM deployment) injects malicious JavaScript into a vulnerable form field, which is stored persistently. When another user - such as an administrator or site visitor reviewing submissions - browses to the page rendering that field, the script executes in their browser, enabling session/cookie theft or actions in the victim's context. No public exploit code was identified at time of analysis, and exploitation still requires the victim to visit the affected page (UI:R).