Adobe Experience Manager CVE-2025-64850

Exploitation requires an authenticated low-privileged AEM account (PR:L) with the ability to submit/save data into one of the affected form fields, plus a separate victim (UI:R) who must subsequently browse to the page rendering the injected field for the stored payload to execute. Affected deployments are AEM 6.5.23 and earlier, AEM Cloud Service, and AEM 6.5 LTS. Limiting factors: no unauthenticated path, mandatory victim interaction, browser-side-only impact (no server compromise), and low confidentiality/integrity effect scoped to the victim's browser session.

All signals point to a genuine but low-priority issue. 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 an authenticated low-privileged account (PR:L) AND victim user interaction (UI:R, the victim must browse to the page hosting the injected field). The scope change (S:C) reflects that injected script runs in the victim's browser trust context rather than the server, and impact is limited to low confidentiality and integrity (C:L/I:L) with no availability effect. EPSS is very low at 0.20% (9th percentile), consistent with the absence of any public exploit and the interaction/auth prerequisites that make mass exploitation impractical. This is NOT in CISA KEV and there is no POC reference - the only source is the Adobe vendor advisory. No SSVC decision data was provided in the input. Net: this is a real, valid stored-XSS bug worth patching in scheduled maintenance, not a fire-drill; the high notional reach of AEM does not translate into high real-world risk because of the compounded low-privilege + user-interaction gating and the limited technical impact.

A low-privileged authenticated AEM user (e.g., a content author) enters a malicious JavaScript payload into a vulnerable form field, which is stored server-side. When another user - such as an administrator or reviewer - later browses to the page rendering that field, the script executes in their browser, enabling session-context actions like cookie/token theft or UI manipulation. No public exploit code is identified at time of analysis, and success depends on a victim actually viewing the affected page.