Adobe Experience Manager CVE-2025-64581

Exploitation requires the attacker to hold a low-privileged authenticated AEM account (PR:L) with the ability to input or edit content in the affected form fields - this is an operator/author-context flaw, not anonymous remote code injection. The stored payload only fires when a victim user actively browses to the page containing the vulnerable field (UI:R), so a second human interaction is required. Limiting factors: valid credentials with form-authoring access are mandatory, victim interaction is required, impact is confined to script execution in the victim's browser (C:L/I:L, no availability impact), and affected deployments are those running AEM 6.5.23 or earlier (including 6.5 LTS and AEM as a Cloud Service builds per the CPEs). No default-configuration unauthenticated path exists.

This is a genuinely moderate-to-low priority issue rather than an urgent one, and the signals are internally consistent. The CVSS 3.1 base score of 5.4 reflects a stored XSS requiring an authenticated low-privileged attacker (PR:L) and victim interaction (UI:R), with only low confidentiality and integrity impact and no availability impact (C:L/I:L/A:N); the scope change (S:C) accounts for script executing in the victim browser context. EPSS corroborates low urgency at 0.25% (15th percentile), indicating little predicted exploitation activity. The CVE is NOT on the CISA KEV list and no public proof-of-concept is referenced, so there is no evidence of active exploitation or weaponization. No SSVC decision data was provided in the input. All signals align - modest CVSS, low EPSS, no KEV, no POC - so there is no conflict to flag. The main caveat is that impact is bounded by the need for a pre-authenticated attacker with form-field access plus a victim who browses the affected page, which materially limits real-world exploitability despite the AV:N network vector.

A low-privileged authenticated user with access to author or edit AEM form fields injects malicious JavaScript into a vulnerable field. The payload is stored and later executed in the browser of any victim (e.g., another author, reviewer, or administrator) who navigates to the page rendering that field, potentially enabling session/token theft or actions in the victim's authenticated context. No public exploit identified at time of analysis.