Adobe Experience Manager CVE-2025-64602

Exploitation requires an authenticated, low-privileged AEM account (PR:L) that can supply content to a vulnerable form field, and the stored payload only executes when a victim user subsequently browses to the page containing that field (UI:R). The attack targets AEM instances where untrusted or lower-tier users can author or edit form field content that is later rendered to other users - making exposure to semi-trusted contributors the key risk condition. Limiting factors that reduce real-world risk: the need for a valid low-privileged account (not unauthenticated), the requirement for victim interaction (a victim must visit the affected page), and impact confined to the victim's browser context (C:L/I:L, no availability impact). Affected deployments include AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS per the CPE data.

This is a moderate-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) in Adobe Experience Manager that is NOT a top-tier emergency priority despite the network attack vector. Multiple signals converge on lower real-world risk: EPSS is only 0.20% (10th percentile), the vulnerability is NOT listed in CISA KEV, and no public proof-of-concept was identified in the provided data. The CVSS vector itself tempers urgency - it requires low-level privileges (PR:L, an authenticated/low-privileged account able to submit form field content) AND victim user interaction (UI:R, a victim must browse to the affected page). The scope change (S:C) and low confidentiality/integrity impact (C:L/I:L, A:N) reflect that script executes in the victim's browser context rather than compromising the server. No signals conflict: the low EPSS, absent KEV, and modest CVSS are all mutually consistent, pointing to a vulnerability worth patching in normal cycles rather than an actively exploited crisis. The primary value lies in session/credential theft or UI manipulation against authenticated AEM users, so prioritize based on exposure of the authoring/form environment to untrusted low-privileged accounts.

A low-privileged authenticated user (e.g., a content contributor with form-authoring rights) injects malicious JavaScript into a vulnerable AEM form field, which is stored persistently. When a higher-privileged victim - such as an administrator or another authenticated user - later browses to the page rendering that field, the script executes in their browser, enabling session hijacking or actions on their behalf. No public exploit code was identified, and successful execution depends on the victim visiting the affected page (UI:R).