Adobe Experience Manager CVE-2025-64605

Exploitation requires the attacker to hold a low-privileged authenticated account in Adobe Experience Manager with the ability to submit or edit content in a vulnerable form field (PR:L), and it further requires a victim to subsequently browse to the page rendering that stored field (UI:R) for the injected JavaScript to execute. These two factors - needing valid (even if low) credentials and requiring victim interaction - are the primary limiting conditions and significantly narrow realistic exploitation to environments where semi-trusted users can author form/field content. Affected deployments include AEM 6.5.23 and earlier, AEM 6.5 LTS, and AEM as a Cloud Service per the provided CPE strings.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) reflects a network-reachable stored XSS that nonetheless requires low-privileged authentication (PR:L) AND victim interaction (UI:R), both of which meaningfully gate exploitation. The EPSS score of 0.25% (15th percentile) is low and aligns with the absence of any CISA KEV listing and no identified public exploit code, so there is no evidence of active or widespread exploitation. The scope change (S:C) is the main aggravating factor - injected script executes in the victim's browser context rather than only the component storing it - but confidentiality and integrity impact are rated Low and availability is None, consistent with typical XSS session/content manipulation rather than full account or server compromise. No SSVC decision data was provided in the input, so automatability and technical-impact framing cannot be cited. Signals are internally consistent (low EPSS, no KEV, no POC, mid-range CVSS requiring auth + interaction); none conflict. Net: patch in a normal cycle, prioritize if the AEM author/form environment is exposed to semi-trusted content contributors.

A low-privileged authenticated user (e.g., a content author or form editor) injects malicious JavaScript into a vulnerable AEM form field, which is stored by the application. When a victim - such as another author or an administrator - later browses to the page rendering that field, the script executes in their browser, enabling session token theft, actions-as-the-victim, or UI redressing. No public exploit code was identified at time of analysis, and exploitation depends on the victim actually visiting the affected page.