Adobe Experience Manager CVE-2025-64577

Exploitation requires the attacker to hold a low-privileged authenticated AEM account (PR:L) with the ability to write to form fields - such as a content author or forms editor role - and requires a victim to subsequently browse to the page that renders the injected field (UI:R). The payload is stored (persistent XSS), so it fires whenever any victim views the affected page. Limiting factors: the attacker cannot be fully unauthenticated, the impact is confined to the victim's browser session (no direct server compromise, A:N), and exploitation depends on another user visiting the poisoned content. Affected deployments include AEM 6.5.23 and earlier, AEM 6.5 LTS, and AEM Cloud Service per the CPE data.

This is a moderate-severity, low-priority issue despite being a network-vector flaw. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, base 5.4) shows that exploitation requires the attacker to already hold low-level authenticated privileges (PR:L) AND requires a victim to interact by browsing to the affected page (UI:R); the scope change (S:C) and low-only confidentiality/integrity impacts (C:L/I:L, A:N) are characteristic of stored XSS executing in another user's browser context rather than compromising the server itself. The EPSS score of 0.25% (15th percentile) indicates very low predicted exploitation probability, consistent with the absence of a CISA KEV listing and no public exploit identified at time of analysis. All signals align downward: no active exploitation, no POC, low EPSS, and meaningful preconditions (authenticated attacker plus victim interaction). No conflicting signals were observed. This is a legitimate defense-in-depth fix for AEM operators but not an emergency; prioritize it in normal patch cycles rather than as an out-of-band response.

A low-privileged authenticated user (e.g., a content author or form editor) injects malicious JavaScript into a vulnerable AEM form field, which is stored persistently. When a higher-privileged user or another victim later browses to the page rendering that field, the script executes in their browser, enabling session token theft or actions in their authenticated context. No public exploit code has been identified for this specific issue.