Adobe Experience Manager CVE-2025-64852

Exploitation requires the attacker to hold a low-privileged authenticated account on the AEM instance (PR:L) with the ability to submit or edit data that populates the vulnerable form field. The payload is stored, so it does not fire immediately - a separate victim user must browse to the page rendering the affected field (UI:R), meaning exploitation is contingent on a second user viewing the injected content. Limiting factors: valid authentication is mandatory, the impact is scoped to the victim's browser (client-side script execution, not server RCE), and confidentiality/integrity impact is rated Low with no availability impact. Applies to AEM 6.5.23 and earlier, including AEM Cloud Service and the 6.5 LTS branch.

This is a genuine but low-priority issue - a classic high-footprint-product, low-real-risk stored XSS. The CVSS 3.1 base score of 5.4 (MEDIUM) is well-calibrated: the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N shows it is network-reachable but double-gated, requiring both low-privilege authentication (PR:L) to inject the payload and victim user interaction (UI:R) to trigger it, with only Low confidentiality and integrity impact and no availability impact. The scope change (S:C) reflects that injected script executes in the victim's browser context rather than the AEM server itself. EPSS reinforces the low-priority read: 0.20% probability at only the 9th percentile, i.e. very low predicted exploitation likelihood. This CVE is NOT in CISA KEV and no public POC was identified, so exploitation status is: no public exploit identified at time of analysis. No SSVC decision point data was supplied in the input. The signals are internally consistent - there is no conflict between CVSS, EPSS, and KEV here; all point to a legitimate defect that is unlikely to be mass-exploited. The main reason not to ignore it entirely is AEM's enterprise deployment footprint and the fact that a low-privilege content author is a plausible internal threat actor.

A low-privileged AEM user (e.g., a content author or form editor) injects a malicious JavaScript payload into a vulnerable form field that is persistently stored. When another user - potentially a higher-privileged administrator - later browses to the page rendering that field, the script executes in their authenticated browser session, enabling session token theft or actions on their behalf. No public exploit code was identified, so exploitation would require an attacker to craft the payload themselves.