Adobe Experience Manager CVE-2025-64572

Exploitation requires an authenticated low-privileged account (PR:L) with the ability to submit/edit content into a vulnerable AEM form field, and it is a STORED XSS, so a payload is persisted and only fires when a victim user subsequently navigates to the page rendering that field (UI:R). This is therefore not a zero-interaction or pre-auth flaw: the attacker needs valid credentials with form-authoring/input capability, and a separate victim must view the affected page for the injected JavaScript to execute in their browser. Limiting factors: required prior authentication, required victim interaction, and impact confined to the browser context (no direct server compromise, A:N). Applies to Adobe Experience Manager 6.5.23 and earlier, including 6.5 LTS and AEM as a Cloud Service.

This is a moderate-severity stored XSS (CVSS 5.4) and the available signals are consistent in pointing to a LOWER real-world priority than a surface reading of 'XSS in a major enterprise CMS' might suggest. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) establishes network reachability and low complexity, but two meaningful friction factors are baked in: the attacker must already hold low-level authenticated privileges (PR:L) to inject into the vulnerable form field, and a victim must subsequently browse to the affected page (UI:R). The scope change (S:C) and dual Low confidentiality/integrity impact reflect that injected JavaScript executes in the victim's browser security context rather than the server's, with no availability impact (A:N). The EPSS score of 0.25% (15th percentile) is low and reinforces that automated mass exploitation is unlikely; stored XSS of this kind is typically leveraged in targeted or opportunistic post-authentication scenarios rather than internet-wide scanning. This CVE is NOT in CISA KEV and no public exploit code was provided in the intelligence set, so there is no confirmed active exploitation. Net assessment: a legitimate issue worth patching on a normal cycle, but not an emergency - the authentication requirement plus required user interaction materially bound its blast radius, and all exploitation/probability signals agree rather than conflict.

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