Adobe Experience Manager CVE-2025-64873

Requires a low-privileged but authenticated AEM account with access to author content in a vulnerable form field (PR:L), plus victim user interaction - a separate user must browse to the page containing the injected field for the stored script to execute (UI:R). Impact is confined to client-side script execution in the victim's browser (C:L/I:L, A:N); there is no server-side code execution. Realistic exposure is limited because AEM authoring interfaces are typically deployed on internal/restricted author instances rather than public-facing, so an attacker needs insider access or a compromised author credential. Affected: AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS.

This is a high-CVSS-context product with a genuinely low real-world risk profile. 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 is internally consistent with the description: network-reachable, but doubly gated by authentication (PR:L - a low-privileged authenticated author/editor account) and victim interaction (UI:R - a victim must browse to the page hosting the injected field). Scope is Changed (S:C) because injected script executes in the victim's browser rather than the AEM server context, but confidentiality and integrity impacts are only Low and availability is None, reflecting limited-scope client-side script execution rather than server compromise. Exploitation signals reinforce the low-priority read: EPSS is 0.20% (9th percentile), there is no CISA KEV listing, and no public proof-of-concept was identified. There is no SSVC data in the input. All signals point the same direction - no conflict between CVSS, EPSS, and KEV. The one caveat is deployment context: AEM is enterprise CMS software where authoring environments should be internal/restricted, which further limits practical exposure to insiders or compromised author accounts.

A low-privileged authenticated AEM author/content contributor injects a malicious JavaScript payload into a vulnerable form field. The script is stored and later executes in the browser of another user (e.g., an editor or reviewer) when they navigate to the page containing that field, potentially enabling session-context actions or credential/UI manipulation. No public exploit code was identified, and exploitation requires both a valid authoring account and victim page interaction.