Adobe Experience Manager CVE-2025-64548

Exploitation requires a low-privileged but authenticated AEM account (PR:L) with the ability to submit data into one of the vulnerable form fields, and it requires a victim to subsequently browse to the page rendering that field (UI:R) for the stored script to execute. It affects AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS. Limiting factors: the attacker cannot exploit anonymously (no PR:N), impact is confined to the victim's browser context with only Low confidentiality/integrity effect and no availability impact, and success depends on victim interaction - so a purely automated, unauthenticated mass-exploitation path does not exist.

This is a genuine but low-priority issue. The CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) reflects a stored XSS that is doubly gated: the attacker must already hold a low-privileged authenticated account (PR:L) AND a victim must browse to the page hosting the injected script (UI:R). The scope change (S:C) recognizes that script executes in the victim's browser origin rather than the injecting component, but confidentiality and integrity impacts are only Low and availability is None. Exploitation-probability signals reinforce the low priority: EPSS is just 0.20% (9th percentile), there is no CISA KEV listing, and no public POC was identified in the provided data. These signals are internally consistent - no conflict between a high CVSS and low real-world exploitation likelihood, since the CVSS itself is only medium. No SSVC decision data was provided. Net assessment: a real, patchable defense-in-depth XSS worth remediating on a normal cycle, not an emergency.

A low-privileged AEM author/contributor account submits a payload containing malicious JavaScript into a vulnerable form field. The script is stored server-side; later, when a higher-privileged user or another visitor browses to the page rendering that field, the JavaScript executes in their browser under the AEM origin, enabling session-context actions such as cookie/token theft or UI manipulation. No public exploit code was identified at time of analysis, and the attack requires both a valid low-priv account and victim page interaction.