Adobe Experience Manager CVE-2025-64612

Exploitation requires an authenticated low-privileged account in Adobe Experience Manager with the ability to edit/submit form fields (PR:L) - it is NOT remote-unauthenticated despite the AV:N network vector. The injected script is stored and only fires when a victim user browses to the page containing the vulnerable form field, so successful attack additionally depends on victim user interaction (UI:R). Key limiting factors: the attacker must already have content/form authoring privileges, and a separate victim must visit the affected page; impact is confined to Low confidentiality and Low integrity in the victim's browser session (no availability impact). Affected deployments are 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, CWE-79) whose real-world priority is low-to-moderate. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N confirms a network-reachable but authenticated attack (PR:L) that additionally requires victim interaction (UI:R), with only Low confidentiality and integrity impact and no availability impact - the Scope:Changed reflects that injected script executes in a separate victim's browser context. The signals are consistent and point AWAY from urgency: EPSS is 0.25% (15th percentile), indicating very low predicted exploitation probability; there is no CISA KEV listing and no public exploit identified at time of analysis. Nothing in the data conflicts with the vector. The chief caveat is that stored XSS in a widely deployed CMS still carries session-hijack and admin-compromise potential if the vulnerable form field is reachable by a lower-trust author and viewed by a higher-privileged user, so it warrants routine patching rather than emergency response. No key data is contradictory; the main gap is the absence of any POC or in-the-wild telemetry to raise or confirm exploitability.

A low-privileged authenticated AEM user (e.g., a content/form author) injects malicious JavaScript into a vulnerable form field, which is stored by the application. When a victim - potentially an administrator or reviewer - later browses to the page rendering that field, the script executes in their browser, enabling session token theft or actions performed as the victim. No public exploit code has been identified, and exploitation requires both authentication and victim page visits.