Adobe Experience Manager CVE-2025-64793

Requires an authenticated account with at least low-privilege content-authoring access to AEM in order to submit input into the affected form field (PR:L). Exploitation also requires victim user interaction (UI:R): a second user must browse to the page that renders the stored malicious field for the script to execute - the attacker cannot trigger execution on demand. Affected deployments are Adobe Experience Manager 6.5.23 and earlier, including AEM Cloud Service and the AEM 6.5 LTS build. This is not a default-config unauthenticated remote flaw; the dual authentication + interaction requirement materially limits realistic exploitation.

This is a genuine-but-low-priority issue: a high-footprint enterprise product with a modest vulnerability. All signals align toward LOW real-world urgency. 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 doubly gated - it requires both low-privileged authentication (PR:L) AND victim user interaction (UI:R, the victim must browse to the page holding the injected field). Impact is limited to C:L/I:L with no availability effect, consistent with a stored XSS that runs script in a single victim's browser session rather than compromising the server. EPSS reinforces this: 0.25% probability at only the 15th percentile indicates very low predicted exploitation likelihood. There is NO CISA KEV listing and NO public POC identified. The scope-change flag (S:C) is the standard XSS convention (script escapes the app's security boundary into the browser context) and does not imply server-side or cross-tenant compromise. No signals conflict - CVSS, EPSS, and the absence of KEV/POC all point the same direction. This is a routine-patch item, not an emergency.

A low-privileged authenticated AEM user (e.g. a content author) injects malicious JavaScript into a vulnerable form field that AEM stores without proper output encoding. When another user - such as an administrator or another author - later browses to the page rendering that field, the script executes in their browser under the AEM origin, enabling session-token theft or actions on their behalf. No public exploit code is identified at time of analysis, and successful attack requires the victim to actually navigate to the affected page.