Adobe Experience Manager CVE-2025-64599

Exploitation requires the attacker to hold a low-privileged authenticated account in Adobe Experience Manager (PR:L) with the ability to enter data into the affected form fields, and succeeds only once a victim actively browses to the page that renders the stored field (UI:R). Affected deployments are AEM 6.5.23 and earlier, including AEM 6.5 LTS and AEM Cloud Service per the CPE data. Limiting factors that reduce realistic risk: the mandatory authenticated-author foothold, the required victim interaction (the payload is passive until someone loads the page), and the Low-only confidentiality/integrity impact bounded by what script execution in the victim's browser session permits. There is no availability impact.

This is a moderate-severity stored XSS (CVSS 5.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) that is a real but not urgent priority. The network attack vector and low complexity favor the attacker, but two factors meaningfully gate exploitation: PR:L means the attacker must already hold a low-privileged authenticated account, and UI:R means a victim must actively browse to the page hosting the injected field. The scope change (S:C) reflects script execution in a victim's browser context beyond the vulnerable component, but confidentiality and integrity impact are only Low and availability is None - consistent with a reflected/stored script-injection flaw rather than full account or server takeover. Exploitation-probability signals all point the same direction and corroborate the modest severity: EPSS is just 0.25% (15th percentile), the CVE is NOT on CISA KEV, and no public exploit code was identified in the provided intelligence. No SSVC decision data was supplied. The signals are mutually consistent - there is no CVSS/EPSS/KEV conflict here - so this reads as a genuine-but-low-real-world-risk issue appropriate for routine patch cycles rather than emergency remediation, with the main caveat being AEM's large enterprise footprint and the authenticated-author threat model (e.g., a rogue or compromised content-author account).

A low-privileged authenticated user (such as a content author or form editor) injects malicious JavaScript into a vulnerable AEM form field, which is stored by the application. When a victim - for example an administrator or another user - later browses to the page rendering that field, the script executes in their browser session. No public exploit code was identified at time of analysis.