Adobe Experience Manager CVE-2025-64794

Exploitation requires: (1) an authenticated account with at least low privileges on the AEM instance (PR:L) - typically an author/content-contributor role able to submit data into the affected form fields; (2) the ability to reach and write to a 'vulnerable form field' that stores attacker-controlled input without proper output encoding; and (3) victim interaction (UI:R) - a second user must navigate to the page rendering the injected field for the script to fire. Limiting factors: this is not exploitable by anonymous/unauthenticated attackers, requires a specific vulnerable form field to be present and reachable, and payload execution depends on another user visiting the page. Affected products are AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS.

This is a genuinely low-priority finding despite being a network-vector vulnerability. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N = 5.4 MEDIUM) is double-gated: it requires an authenticated low-privileged attacker (PR:L) AND victim user interaction (UI:R - the victim must browse to the page hosting the injected field). Impact is limited to C:L/I:L with no availability impact, consistent with a stored XSS that runs script in a victim's browser session rather than compromising the server. Exploitation signals reinforce low urgency: EPSS is 0.25% (15th percentile), there is no CISA KEV listing, and no public POC is identified. No SSVC decision data was supplied. Bottom line: no signal conflict - CVSS, EPSS, and exploitation status all point the same direction. This is a real but low-real-risk issue that fits routine patch cycles, not emergency remediation. The main aggravating factor is the enterprise context: AEM instances are authoring/CMS platforms where a low-priv author account is a plausible attacker and cross-tenant/cross-user script execution (scope-change S:C) can affect other users' sessions.

A low-privileged authenticated AEM author injects malicious JavaScript into a vulnerable form field. When another user - for example a reviewer or higher-privileged administrator - browses to the page containing that field, the script executes in their browser, enabling session-context actions such as cookie/token theft or CSRF-style requests. No public exploit code has been identified, so an attacker would need to develop the payload themselves.