Adobe Experience Manager CVE-2025-64574

Requires an authenticated low-privileged AEM account (PR:L) with the ability to write to a vulnerable form field, and requires a victim to subsequently browse to the page rendering that stored field (UI:R) for the script to execute. Exploitation is limited to Adobe Experience Manager 6.5.23 and earlier (including the 6.5 LTS and AEM Cloud Service CPEs listed); it is NOT remote-unauthenticated and does not work without both a valid foothold account and victim interaction. Impact is confined to confidentiality and integrity within the victim's browser context (C:L/I:L, A:N) with a scope change into the victim's session.

This is a genuinely moderate-risk, not high-priority, issue and the signals are internally consistent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, base 5.4 Medium) describes a network-reachable stored XSS that nonetheless requires an authenticated low-privileged account (PR:L) AND victim interaction (UI:R) - two meaningful gating factors that keep this out of the critical tier. EPSS reinforces low urgency at 0.20% (9th percentile), indicating very low near-term exploitation probability. The flaw is NOT in CISA KEV and no public POC was supplied, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data was provided in the input. The scope change (S:C) and reflected impact on a victim's browser are typical of stored XSS and explain the elevated-but-still-Medium score. Bottom line: all signals agree this is a real but low-likelihood issue requiring an insider/foothold plus a tricked victim - patch in normal cycle rather than emergency. Note: no independent confirmation of exploitation exists, and the sole reference (APSB25-115) is an Adobe advisory whose slug year (25-115) matches a 2025 bulletin consistent with the CVE year.

An authenticated low-privileged author or form user injects a malicious JavaScript payload into a vulnerable AEM form field that is persisted server-side. When a higher-privileged user or other visitor 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 authenticated context. No public exploit code was identified, and successful execution depends on the victim actually visiting the affected page (UI:R).