Adobe Experience Manager CVE-2025-64614

Exploitation requires an attacker to hold a low-privileged authenticated account in Adobe Experience Manager (PR:L) capable of editing a vulnerable form field, and a separate victim must subsequently browse to the page that renders the stored field (UI:R) for the injected JavaScript to execute. Affected deployments are AEM versions 6.5.23 and earlier (including the 6.5 LTS line and referenced AEM Cloud Service CPE). Limiting factors: no unauthenticated path exists, the payload only triggers on victim page load, and impact is confined to script execution in the victim's browser (C:L/I:L, no availability impact) rather than direct server-side compromise.

This is a moderate, not a 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) describes a stored XSS that is network-reachable with low complexity, but exploitation is gated by two meaningful factors: the attacker must already hold low-level privileges (PR:L) to inject into the vulnerable form field, and a victim must be induced to browse the affected page (UI:R). The scope change (S:C) and dual low confidentiality/integrity impact reflect script execution in a victim's browser context rather than direct server compromise. Real-world urgency signals are weak and consistent with each other: EPSS is only 0.25% (15th percentile), there is no CISA KEV listing, and no public exploit code was identified in the provided data - all pointing to low likelihood of widespread opportunistic exploitation. No signals conflict. The dominant limiting factor is the required low-privileged authenticated access combined with victim interaction, which keeps this well below the profile of an unauthenticated RCE despite the network attack vector.

A low-privileged authenticated user (e.g., a content author) injects malicious JavaScript into a vulnerable AEM form field, which is stored persistently. When another user - such as an administrator or site visitor - later browses to the page rendering that field, the script executes in their browser, potentially stealing session tokens or performing actions in their context. No public exploit code was identified at time of analysis, and exploitation requires both prior low-level access and victim interaction.