Adobe Experience Manager CVE-2025-64609

Exploitation requires an authenticated low-privileged account (PR:L) with the ability to write to one of the affected AEM form fields, so an attacker must already have content-authoring or equivalent write access to the instance. Successful triggering also requires victim interaction (UI:R): a separate user must subsequently browse the page that renders the stored payload. These two factors - prior authenticated write access and a browsing victim - materially limit realistic exploitation. Affected scope is Adobe Experience Manager 6.5.23 and earlier, including AEM 6.5 LTS and AEM as a Cloud Service per the supplied CPEs.

This is a moderate-severity stored XSS (CVSS 5.4) that does not rise to an urgent operational priority. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N shows network reach and low complexity, but two meaningful brakes: it requires an authenticated low-privileged account (PR:L) to inject the payload, and a victim must browse the affected page (UI:R). The scope change (S:C) reflects that injected script executes in the victim's browser outside the vulnerable component's boundary, but confidentiality and integrity impacts are only Low and availability is None. All corroborating exploitation signals point low: EPSS is 0.25% (15th percentile), there is no CISA KEV listing, and no public POC is referenced. These signals are consistent with each other - a low EPSS aligns with the absence of KEV/POC - so there is no conflict to flag. Net assessment: a real but low-to-moderate risk best handled on a normal patch cadence rather than emergency remediation. No SSVC decision data was supplied in the input, so exploitation-status/automatable/technical-impact framing cannot be independently applied beyond the CVSS and EPSS signals above.

A low-privileged authenticated user (e.g. a content author) injects malicious JavaScript into a vulnerable AEM form field. When a higher-privileged user or another visitor later browses the page rendering that field, the stored script executes in their browser, enabling session/cookie theft or UI actions in their context. No public exploit code is identified at time of analysis, and victim interaction (loading the page) is required.