Adobe Experience Manager CVE-2025-64603

Exploitation requires an authenticated low-privileged AEM account (PR:L) with the ability to submit/edit content into a vulnerable form field, and a separate victim who must actively browse to the page rendering that field (UI:R) - it is not a drive-by, unauthenticated, or fully automated attack. The specific vulnerable form field is not named in the available data, so the affected feature cannot be pinpointed beyond 'form fields' in AEM 6.5.23 and earlier (including AEM Cloud Service and 6.5 LTS per the CPE list). Limiting factors: the required write access to form content and the dependency on a victim visiting the stored content substantially reduce opportunistic mass exploitation, making this better suited to insider or multi-user-tenant scenarios where a lower-privileged user can seed content viewed by administrators.

This is a genuine-but-moderate priority, not a top-tier emergency. The CVSS 3.1 base score of 5.4 (Medium) reflects a stored XSS that requires both low-level authenticated privileges (PR:L) and victim user interaction (UI:R), which meaningfully constrain real-world abuse despite the network attack vector (AV:N) and low attack complexity (AC:L). The scope change (S:C) earns a slight uplift because injected script executes in the victim's browser context rather than the vulnerable component, but confidentiality and integrity impacts are only Low (C:L/I:L) and there is no availability impact (A:N). Exploitation signals are weak and mutually consistent: EPSS is 0.25% (15th percentile), the CVE is NOT on the CISA KEV list, and no public exploit code is identified - so there is no public exploit identified at time of analysis. All signals align (low EPSS, no KEV, no POC, medium CVSS), so there is no conflict to flag; the main reason to patch is that AEM is a widely deployed enterprise CMS and stored XSS can be chained against higher-privilege administrators who view attacker-controlled form content.

A low-privileged authenticated user (e.g., an author or form editor) injects malicious JavaScript into a vulnerable AEM form field, which is persistently stored. When a higher-privileged victim, such as a content administrator, later browses to the page rendering that field, the script executes in their authenticated browser session, enabling session/token theft or actions on their behalf. No public exploit code is identified at time of analysis.