Adobe Experience Manager CVE-2025-64607

Exploitation requires an authenticated low-privileged AEM account (PR:L) with the ability to submit content into form fields that AEM stores and later renders without proper output encoding - this is the stored XSS sink. Successful attack also requires victim interaction (UI:R): a separate user must subsequently browse to the page containing the injected field for the JavaScript to execute in their browser. Limiting factors: the attacker cannot act fully unauthenticated, impact is confined to the victim's browser session (no direct server compromise), and payload delivery depends on another user visiting the affected page. This applies to Adobe Experience Manager on-premise/LTS 6.5.23 and earlier as listed in the CPE data.

This is a moderate-severity, low-priority issue rather than an urgent one. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N, base 5.4) describes a network-reachable but constrained flaw: it requires an authenticated low-privileged account (PR:L) and victim interaction (UI:R), and yields only limited confidentiality and integrity impact with no availability impact. The scope change (S:C) reflects that injected script executes in a victim's browser context rather than the AEM server itself - typical of stored XSS. Corroborating signals all point low: EPSS is 0.25% (15th percentile), indicating very low near-term exploitation probability; the CVE is NOT on CISA KEV; and no public POC is referenced. There is no conflict between the signals - the CVSS, EPSS, and absence of KEV/POC are mutually consistent in describing a real but non-critical vulnerability. The main caveat is that exploitation presumes an attacker already holds a low-privileged authenticated account on the AEM instance, which meaningfully narrows the realistic threat to insiders or attackers who have already gained a foothold.

A low-privileged authenticated user (e.g., a content author or form editor) injects malicious JavaScript into a vulnerable AEM form field, which is stored persistently. When a higher-privileged user or site visitor later browses to the page containing that field, the script executes in their browser, enabling session/cookie theft or actions performed as the victim. No public exploit code is referenced, so exploitation would require an attacker to develop their own payload.