Adobe Experience Manager CVE-2025-64596

Exploitation requires a low-privileged but authenticated AEM account (PR:L) with the ability to write content into form fields - consistent with an author, form editor, or content-contributor role rather than an anonymous user. The stored payload only executes when a victim (another user or administrator) subsequently browses to the page containing the injected field, so required victim user interaction (UI:R) is the key limiting factor. Affected deployments are Adobe Experience Manager 6.5.23 and earlier, including the 6.5 LTS and AEM Cloud Service CPE configurations. There is no remote unauthenticated exploitation path and no automatable mass-exploitation vector; impact is confined to the victim's browser session (low confidentiality/integrity, no availability impact).

This is a moderate-severity stored XSS (CVSS 5.4, CWE-79) that the signals consistently rank as a lower operational priority despite affecting a widely-deployed enterprise product. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) shows network reach and low attack complexity, but requires an authenticated low-privileged account (PR:L) AND victim interaction (UI:R), with only low confidentiality and integrity impact and no availability impact. These limiting factors align with the EPSS score of 0.25% (15th percentile), indicating low predicted exploitation probability. The CVE is NOT in CISA KEV and no public exploit code is referenced, so there is no evidence of active or automatable exploitation. No SSVC decision data was provided. In short, this is a genuine flaw in a high-footprint product but a high-CVSS-but-moderate-real-risk issue: the combination of required authentication, required user interaction, and limited impact scope argues for routine patching priority rather than emergency response. No signals conflict - all point to the same lower-urgency conclusion.

A low-privileged authenticated user (e.g., a content author or form editor) injects malicious JavaScript into a vulnerable AEM form field. The script is stored and later executes in the browser of any victim - such as another author or administrator - who navigates to the page containing the field, potentially enabling session token theft or actions in the victim's authenticated context. No public proof-of-concept exploit is referenced.