Adobe Experience Manager CVE-2025-64861

Requires an authenticated account with at least low-privilege access to a vulnerable AEM form-editing/authoring feature (PR:L) - not exploitable by anonymous users. The attacker injects script into a specific vulnerable form field which is persisted; exploitation only completes when a separate victim user navigates to the page rendering that field (UI:R), so it cannot fire without victim interaction. Applies to AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS. Impact is confined to the victim's browser context within the AEM application (client-side script execution, C:L/I:L); there is no server-side code execution or availability impact.

This is a genuinely LOW-priority issue despite being a network-vector XSS. All signals align on low real-world risk: 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) is doubly gated - it requires an already-authenticated low-privileged account (PR:L) AND victim user interaction (UI:R, the victim must browse to the page holding the injected field). EPSS is very low at 0.20% (9th percentile), indicating the ecosystem does not expect exploitation. There is no CISA KEV listing and no public POC identified at time of analysis, so exploitation status is 'no public exploit identified at time of analysis'. No SSVC decision data was supplied. Impact is limited to C:L/I:L with A:N - a stored XSS running in the victim's browser session, not server compromise. There are no conflicting signals: the vector, EPSS, and absence of exploitation evidence all point the same way. The only mild elevation comes from AEM being an enterprise CMS often handling privileged marketing/author sessions, so the scope-change (S:C) and cross-user script execution have some value to an insider or a compromised low-priv author account. Overall: a high-CVSS-optics but low-real-risk authenticated, click-gated XSS - patch on normal cycle, not an emergency.

A low-privileged authenticated user (e.g. a limited AEM author or form editor) injects malicious JavaScript into a vulnerable form field that is persisted server-side. When a higher-privileged author or another user later browses to the page containing that field, the stored script executes in their browser, potentially stealing their AEM session token or performing actions as them within the CMS. No public exploit code is currently available, and both authentication and victim interaction are required.