Adobe Experience Manager CVE-2025-64619

Exploitation requires an authenticated low-privileged account with the ability to write to AEM form fields (PR:L) - typically a content author, form editor, or contributor role - meaning it is NOT exploitable by fully anonymous attackers. It additionally requires victim user interaction (UI:R): a separate user must browse to the page rendering the injected field for the payload to fire. The impact scope crosses into the victim's browser (S:C), so the realistic target is other logged-in users (e.g., administrators or reviewers) or site visitors viewing the affected content. Applies to AEM 6.5.23 and earlier, AEM 6.5 LTS, and AEM as a Cloud Service per the published CPE set; the primary limiting factors are the required content-authoring privilege and the dependency on a victim visiting the poisoned page.

This is a moderate-severity, low-priority issue despite affecting a widely-deployed enterprise platform. The CVSS 3.1 base score of 5.4 (vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) reflects the inherent limits of stored XSS: although network-reachable and low-complexity, it requires an authenticated low-privileged attacker (PR:L) to plant the payload AND a victim to subsequently browse the affected page (UI:R), with only Low confidentiality and integrity impact and no availability impact. The multi-source signals are mutually consistent and all point AWAY from urgent exploitation: EPSS is 0.25% (15th percentile), placing it in the low-probability band; there is no CISA KEV listing and no public exploit code identified. The scope change (S:C) is the one elevating factor, correctly capturing that injected script executes in the victim's browser context rather than the application's. No signals conflict here - a genuinely authenticated, user-interaction-dependent stored XSS with low EPSS and no known exploitation is a routine patch-cycle item, not an emergency. The main residual risk is that AEM is a content-authoring platform where low-privileged content contributors legitimately exist, so the PR:L barrier is realistically met inside many organizations, and a victim with higher privileges (e.g., an administrator reviewing content) could be a valuable target for session/credential theft.

A low-privileged AEM content author or form editor injects a malicious JavaScript payload into a vulnerable form field, which is stored and later rendered. When a higher-privileged user or site visitor browses the page containing that field, the script executes in their browser, enabling session token theft, actions-on-behalf, or UI redress. No public exploit code has been identified, but stored XSS in form fields is straightforward to reproduce once access is obtained.