Adobe Experience Manager CVE-2025-64593

Exploitation requires a low-privileged authenticated AEM account (PR:L) with the ability to write content into a vulnerable form field, plus a subsequent victim who browses to the page rendering that stored field (UI:R) - the payload does not fire until a user views the affected page. This is a stored/persistent XSS, so it affects AEM form-authoring workflows where untrusted or lower-tier authors can submit field content; it is not remote-unauthenticated. Limiting factors: the required authenticated write access, the dependency on victim interaction, and applicability to the specific vulnerable form-field feature rather than arbitrary default pages. Affected: AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS per the provided CPEs.

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) whose real-world urgency signals all point to low priority rather than emergency patching. The attack vector is network-reachable with low complexity, but exploitation requires a low-privileged authenticated account (PR:L) AND victim interaction (UI:R), both of which meaningfully constrain opportunistic exploitation. The scope change (S:C) and dual C:L/I:L impacts are consistent with script execution crossing from the injected form field into a victim's browser/session context. Corroborating the low-urgency reading: EPSS is 0.20% (10th percentile), there is no CISA KEV listing, and no public exploit code was provided in the input. No SSVC decision data was supplied. In short, the signals are internally consistent - a genuine but low-to-moderate risk flaw gated by authentication and user interaction, not a high-CVSS-but-overrated issue nor an actively-exploited emergency. No conflicting signals were found; the main caveat is simply that absence of POC/KEV data does not guarantee no exploit exists, only that none was reported here.

A low-privileged user (e.g., a content author or form editor) injects malicious JavaScript into a vulnerable AEM form field, which is stored by the application. When a victim - such as another author or an end user - later browses to the page rendering that field, the script executes in their browser under the application's origin, enabling session/cookie theft or actions in the victim's authenticated context. No public exploit code was identified at time of analysis.