Adobe Experience Manager CVE-2025-64598

Requires an authenticated low-privileged account (PR:L) with the ability to enter data into the affected form fields, plus a victim who subsequently browses to the page rendering the stored payload (UI:R) - so exploitation is not self-triggering. Affected deployments are Adobe Experience Manager 6.5.23 and earlier (including the referenced on-prem/LTS and AEM Cloud Service CPEs). Limiting factors: attacker must already have content/form-editing privileges, victim interaction is mandatory, and impact is confidentiality/integrity 'Low' with no availability impact; environments that restrict untrusted users from authoring form content substantially reduce exposure.

This is a stored XSS flaw (CWE-79) in Adobe Experience Manager with a moderate CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N). The network attack vector and low complexity are offset by two meaningful constraints: the attacker must already hold low-level privileges (PR:L) to inject into form fields, and a victim must then browse to the affected page (UI:R), so exploitation is not fully unauthenticated or automatic. The scope change (S:C) reflects that injected script executes in the victim's browser context rather than only the vulnerable application. Real-world exploitation signals are low: EPSS is 0.25% (15th percentile), there is no CISA KEV listing, and no public exploit identified at time of analysis. The signals are consistent rather than conflicting - a medium-severity, authenticated, interaction-dependent XSS with low exploitation probability. This is a patch-in-normal-cycle issue rather than an emergency; it is most relevant where low-privileged content authors are not fully trusted. No key data is contradictory, though note that only a limited-privilege attacker (e.g., a content author) can plant the payload, which bounds the realistic threat population.

A low-privileged AEM user (such as a content author with form-editing rights) injects malicious JavaScript into a vulnerable form field. The payload is stored, and when a higher-privileged user or site visitor later browses to the page containing that field, the script executes in their browser, enabling session/token theft or actions in their context. No public exploit code was identified at the time of analysis.