Adobe Experience Manager CVE-2025-64601

Exploitation requires an authenticated account with at least low privileges in Adobe Experience Manager (PR:L) capable of writing to the vulnerable form field, plus a victim who subsequently browses to the page rendering that field (UI:R) - the payload is stored and only fires when the victim loads the page. Limiting factors: the attacker must already have a content-authoring or form-submission foothold, the malicious content must survive any input sanitization in the affected form workflow, and a separate victim must view the poisoned page for impact to occur. Affected deployments are AEM 6.5.23 and earlier, AEM 6.5 LTS, and AEM Cloud Service per the CPE data; this is not remote-unauthenticated against a default install.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 base score of 5.4 (Medium) reflects meaningful but bounded risk: network attack vector (AV:N) and low complexity (AC:L) ease delivery, but exploitation requires low-level privileges (PR:L) and victim user interaction (UI:R), with only Low confidentiality and integrity impact and no availability impact. The changed scope (S:C) correctly captures that injected script executes in a victim's browser context, crossing from the application to the user. Exploitation signals are quiet and mutually consistent: EPSS is 0.25% (15th percentile), indicating low predicted exploitation probability; the CVE is NOT on CISA KEV; and no public exploit code is referenced. There is no conflict between signals here - all point to a stored XSS that requires an authenticated foothold and a victim visiting the poisoned page, which argues for patch-cycle prioritization rather than emergency response. The main risk amplifier is product prevalence: AEM is a widely deployed enterprise CMS, and stored XSS in authoring/form workflows can be leveraged for session theft or privilege escalation against higher-privileged editors or site visitors.

A low-privileged authenticated user (e.g., a form author or content contributor) injects malicious JavaScript into a vulnerable AEM form field, which is stored persistently. When a victim - such as a site visitor or a higher-privileged administrator reviewing content - browses to the page containing the field, the script executes in their browser, enabling session hijacking or actions on their behalf. No public exploit code is identified at time of analysis, and the attack depends on the victim loading the affected page (UI:R).