Adobe Experience Manager CVE-2025-64557

Exploitation requires the attacker to hold a low-privileged authenticated account on the AEM instance (PR:L) with the ability to write to one of the vulnerable form fields, and requires a victim user to subsequently browse to the page rendering that field (UI:R). Both conditions must be met - this is not remotely exploitable against an unauthenticated or default anonymous configuration. Affected deployments are AEM 6.5.23 and earlier, including AEM Cloud Service and the 6.5 LTS line. The limiting factors - required authentication plus required victim interaction plus only low confidentiality/integrity impact - substantially reduce realistic risk below what the network attack vector alone might suggest.

This is a genuinely low-priority issue despite being in a widely-deployed enterprise CMS. 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) is double-gated: it requires low-privilege authentication (PR:L) to inject the payload AND victim user interaction (UI:R) - the victim must browse to the page containing the malicious form field. Impact is limited to C:L/I:L (client-side script execution in the victim's browser, no availability impact). EPSS reinforces the low priority at just 0.25% (15th percentile), indicating minimal predicted exploitation activity. There is no CISA KEV listing and no public exploit code identified, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was provided. Signals are consistent across the board - moderate raw CVSS, low EPSS, no KEV, no POC - with no conflicts to flag. The scope change (S:C) reflects XSS crossing the security boundary into the victim's browser session, which is standard for stored XSS and appropriately captured. This is a real but low-severity finding: patch on normal cadence, not an emergency.

A low-privileged authenticated AEM user (e.g., a content author) injects a malicious JavaScript payload into a vulnerable form field. When a higher-privileged victim (such as an administrator or another author) later browses to the page rendering that field, the stored script executes in their browser session, potentially enabling session token theft or actions in the victim's context. No public proof-of-concept exploit has been identified, and both authentication and victim interaction are required, limiting real-world exploitability.