Adobe Experience Manager CVE-2025-64606

Exploitation requires an authenticated account with at least low-level privileges in Adobe Experience Manager (PR:L) - specifically the ability to write to the affected form field - meaning this is not reachable by anonymous/unauthenticated users. It further requires victim interaction (UI:R): the injected script only fires when a user navigates to the page rendering the stored field, so a victim must view the malicious content for impact to occur. These two factors (required authoring access plus a browsing victim) are the primary limiters and apply to AEM 6.5.23 and earlier, AEM 6.5 LTS, and AEM as a Cloud Service per the listed CPEs; no special non-default configuration is called out in the description.

This is a moderate-severity stored XSS (CWE-79) that the collected signals consistently rank as a low-to-moderate real-world priority rather than an urgent threat. The Adobe-issued CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, base 5.4) shows network-reachable but authenticated exploitation (PR:L) that additionally depends on victim interaction (UI:R), which materially caps impact. EPSS reinforces this: 0.25% probability at the 15th percentile indicates very low expected exploitation volume. There is no CISA KEV listing and no public exploit was identified at time of analysis, so this is 'no public exploit identified at time of analysis.' No SSVC decision record was provided in the input, so exploitation-status/automatable/technical-impact cannot be cited from a vendor SSVC framework - this is a gap, not a conflict. The signals do not conflict: a mid-range CVSS, low EPSS, no KEV, and no POC all point the same direction. The main caveat is that stored XSS in an enterprise authoring platform can still be leveraged for targeted session/credential theft or privilege-escalation chains against higher-privileged users (e.g., an author tricking an administrator), so it should be patched in the normal cycle but does not warrant emergency response.

A low-privileged authenticated AEM author (PR:L) injects malicious JavaScript into a vulnerable form field; the payload is stored and later rendered when a victim - potentially a higher-privileged editor or administrator - browses the page containing that field (UI:R), executing the script in their authenticated browser session. No public exploit code was identified, and successful abuse requires both valid low-level access and a victim viewing the affected content.