Adobe Experience Manager CVE-2025-64841

Requires an authenticated low-privileged AEM account (PR:L) with the ability to submit content into a vulnerable form field on Adobe Experience Manager 6.5.23 or earlier, including AEM Cloud Service and AEM 6.5 LTS. Exploitation is further gated by victim user interaction (UI:R): the injected script only runs when another user browses to the page hosting the affected field. Limiting factors: no unauthenticated path, dependence on a victim visiting the specific page, and impact confined to the browser (no server-side code execution or availability loss). Realistic risk is highest in deployments with many or untrusted content authors.

This is a genuinely MEDIUM-severity issue that in practice is LOW priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N = 5.4) is internally consistent with the description: network-reachable but double-gated by two independent requirements - the attacker must hold low-privilege authenticated access (PR:L) to reach the vulnerable form field, and a victim must subsequently browse to the page for the injected script to fire (UI:R). Impact is limited to C:L/I:L with no availability effect; the scope change (S:C) reflects XSS crossing the browser trust boundary rather than server compromise. All exploitation signals point the same way: EPSS is 0.20% (9th percentile), there is no CISA KEV listing, and no public POC is referenced. No SSVC data is provided, but the low automatability (requires authenticated injection plus a victim clicking) and partial technical impact would place this in a 'Track'-not-'Act' posture. No signals conflict - the CVSS, EPSS, and exploitation status all agree this is a stored-XSS hygiene fix rather than an emergency. The only elevating factor is that AEM is a widely deployed enterprise CMS, so the finding matters for organizations with untrusted or numerous low-privilege content authors.

A low-privileged AEM content author or form user injects a malicious JavaScript payload into a vulnerable form field, which is stored server-side. When an administrator or another user later browses the page containing that field, the script executes in their authenticated browser session, enabling session-context actions or data theft. No public exploit code is identified, and exploitation still requires the victim to visit the affected page.