Adobe Experience Manager CVE-2025-64611

Exploitation requires a low-privileged authenticated AEM account with the ability to edit or submit content into the vulnerable form fields (PR:L), and the stored payload only fires when a victim subsequently browses to the page rendering that field (UI:R) - it is not fully self-triggering. Affected deployments are limited to Adobe Experience Manager 6.5.23 and earlier (including the 6.5 LTS and listed on-prem/cloud CPE variants). Limiting factors that reduce real-world risk: the attacker must already hold a content-authoring privilege level, a second user must view the injected content, and the impact is confined to the victim's browser session (no direct server compromise, A:N).

This is a medium-severity stored XSS (CVSS 5.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) that should be treated as a patch-in-normal-cycle issue rather than an emergency. The signals are internally consistent and point to limited real-world risk: the EPSS score is low at 0.25% (15th percentile), there is no CISA KEV listing, and no public exploit was identified at time of analysis - so the only elevated signal is the CVSS network attack vector, which is normal for any web-delivered XSS. The vector itself tempers the score: exploitation requires low-privileged authentication (PR:L) and victim user interaction (UI:R), meaning an attacker must already hold an account capable of editing form fields and must wait for a victim to visit the affected page. The scope change (S:C) and Low confidentiality/integrity impact reflect script execution in the victim's browser context rather than compromise of the AEM server itself; availability impact is None. No SSVC decision data was provided in the input. No signals are in conflict - low EPSS, no KEV, and no POC all align with a genuine but non-urgent, authenticated, interaction-dependent web vulnerability.

A low-privileged AEM author or form editor injects a malicious JavaScript payload into a vulnerable form field. When a victim - such as a content reviewer or another authenticated user - later browses to the page rendering that field, the stored script executes in their browser, enabling session/cookie theft or actions performed as the victim. No public exploit code was identified at time of analysis, so an attacker would need to craft the payload independently.