Adobe Experience Manager CVE-2025-64620

Requires a low-privileged authenticated AEM account with the ability to write into a vulnerable form field (per PR:L and the description's 'low privileged attacker'), and requires a victim to subsequently browse to the page containing the injected field (per UI:R). Exploitation is therefore limited by: (1) the need for prior authenticated access to an authoring/form-editing capability, (2) dependence on victim interaction (viewing the affected page), and (3) the affected version range - AEM 6.5.23 and earlier, 6.5 LTS, and AEM Cloud Service. It is not remote-unauthenticated and does not work against a read-only or unauthenticated attacker.

This is a moderate-severity stored XSS (CWE-79) with a self-consistent CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, 5.4) whose signals all point to a low-to-moderate real-world priority rather than an emergency. The network attack vector and low complexity are offset by two meaningful constraints: PR:L means the attacker must already hold low-privileged authenticated access (e.g., an authoring account), and UI:R means a victim must actively browse to the page hosting the poisoned field. The scope change (S:C) and C:L/I:L impacts reflect that injected script executes in the victim's browser session across a trust boundary, but there is no availability impact and only limited confidentiality/integrity effect. Exploitation evidence is weak: EPSS is 0.25% at the 15th percentile (low predicted exploitation), there is no CISA KEV listing, and no public exploit code is identified at time of analysis - consistent signals that this is not being broadly weaponized. No signals conflict with each other here. Bottom line: a legitimate flaw worth patching in the normal cycle, but not a drop-everything issue given the authentication prerequisite, required user interaction, and absence of exploitation evidence.

An attacker with a low-privileged authoring account in Adobe Experience Manager injects malicious JavaScript into a vulnerable form field. The script is stored and later executes in the browser of any higher-privileged user or site visitor who navigates to the page rendering that field, enabling session/token theft or actions in the victim's context. No public exploit code is identified at time of analysis.