Adobe Experience Manager CVE-2025-64615

Exploitation requires an authenticated low-privileged account (PR:L) with the ability to write to the affected AEM form fields, so an insider or compromised author/editor credential is a prerequisite - this is not remote-unauthenticated. Successful payload execution also depends on a separate victim navigating to the page containing the injected field (UI:R), meaning the script lies dormant until viewed. Limiting factors: the attacker cannot self-trigger impact, the stored payload affects only users who browse the specific vulnerable page, and impact is confined to the victim's browser session (no server compromise or availability loss). Affected deployments are AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS per the CPE data.

This is a moderate-severity stored XSS (CVSS 5.4, CWE-79) that scores well below the critical tier and is corroborated by low-exploitation signals: EPSS is 0.25% (15th percentile), there is no CISA KEV listing, and no public proof-of-concept was identified in the provided data. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N confirms this is network-reachable but gated by two meaningful barriers - the attacker must already hold low-level authenticated privileges (PR:L) to inject into the form field, and a victim must subsequently browse the poisoned page (UI:R). The scope change (S:C) reflects that injected script executes in the victim's browser context rather than the AEM server, and impact is limited (C:L/I:L/A:N - no availability impact). All signals are internally consistent: there is no conflict between the low EPSS and the absence of KEV/POC, which together point to a low likelihood of opportunistic mass exploitation. This is best treated as a routine-priority patch for a high-value enterprise CMS rather than an emergency; the realistic risk is targeted abuse by an authenticated insider or a low-privileged author account used to attack higher-privileged reviewers/administrators who view the content.

A low-privileged AEM author or form-editor account injects malicious JavaScript into a vulnerable form field, storing it in the page. When a higher-privileged user or site visitor later browses to the page, the script executes in their browser (UI:R), enabling session token theft or actions in the victim's authenticated context. No public exploit code was identified, but stored XSS in CMS form fields is straightforward to weaponize once author access is obtained.