Adobe Experience Manager CVE-2025-64863

Exploitation requires an authenticated low-privileged AEM account (PR:L) with the ability to submit or edit content into a vulnerable form field, plus a victim who must subsequently browse to the page rendering that field (UI:R). The stored payload only fires in the victim's browser on page view - there is no server-side code execution. Limiting factors: valid author-tier credentials are needed (not unauthenticated), the attack depends on victim interaction, and impact is confined to the browser context (C:L/I:L, no availability effect). Applies to AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS per the CPE data.

This is a genuine but low-priority issue - a high-value product with a low-impact flaw. All signals align toward low real-world urgency: the CVSS 3.1 base score is 5.4 (Medium), and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N shows exploitation is doubly gated by both authentication (PR:L, a low-privileged AEM author account) and victim interaction (UI:R, a victim must browse to the page holding the injected field). Impact is limited to C:L/I:L (partial confidentiality/integrity via script execution in the victim's browser) with no availability impact. EPSS is 0.20% (9th percentile), among the lowest tiers, indicating negligible predicted exploitation activity. The vulnerability is NOT in CISA KEV, and no public proof-of-concept is referenced - so exploitation status is 'no public exploit identified at time of analysis.' The scope change (S:C) correctly reflects XSS crossing from the AEM application into the victim's browser context. No signals conflict: low CVSS, low EPSS, no KEV, and no POC all point the same direction. The only mild elevator is that AEM is enterprise CMS software often exposed to authenticated content authors, but the prerequisite of an existing low-priv account plus required user interaction keeps realistic risk low. Treat as routine patch-cycle remediation, not an emergency.

A low-privileged AEM author or form-editor user injects a malicious JavaScript payload into a vulnerable form field that is persisted server-side. When a victim (e.g., another author or an admin) later browses to the page rendering that field, the stored script executes in their browser session, enabling session-token theft or actions in the victim's authenticated context. No public POC is referenced, and exploitation requires both a valid low-priv account and the victim visiting the affected page.