Adobe Experience Manager CVE-2025-64623

Exploitation requires a low-privileged but authenticated AEM account (PR:L) that can write to one of the affected form fields, and it only succeeds when a victim subsequently navigates to the page rendering the injected field (UI:R) - the payload does not fire on its own. Because the flaw is a stored XSS in form-field handling, the practical conditions are: (1) attacker has content-editing/form-submission privileges on an AEM 6.5.23-or-earlier instance (including AEM Cloud Service or 6.5 LTS per the CPEs), and (2) a second, typically higher-value user views the stored content. Limiting factors that reduce real-world risk: the required authentication floor, the dependency on victim interaction, and only Low confidentiality/integrity impact (no availability impact). This is not remotely exploitable against an unauthenticated attacker.

This is a moderate-severity stored XSS (CVSS 5.4) in Adobe Experience Manager, and the combined signals point to a genuine-but-non-urgent issue rather than a top-priority emergency. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) indicates network-reachable, low-complexity exploitation that requires a low-privileged authenticated account AND victim user interaction, with a scope change reflecting that the injected script executes in a different security context (the victim's browser/session). EPSS reinforces low real-world urgency: 0.25% probability at the 15th percentile, consistent with a stored XSS that depends on both attacker authentication and victim browsing. There is no CISA KEV listing and no public exploit identified in the provided data, so there is no evidence of active exploitation or weaponization. The signals are mutually consistent - low EPSS, moderate CVSS, authenticated+interaction prerequisites, and only Low confidentiality/integrity impact all align - so this is best treated as a routine patch-cycle item, prioritized for internet-facing AEM author/publish instances with multi-user access rather than as an immediate drop-everything fix. No key signals conflict; the main limitation is that exact affected sub-versions and the fixed build are known only from the single Adobe advisory reference, not independently cross-verified here.

A low-privileged authenticated user (e.g., a content contributor) injects malicious JavaScript into a vulnerable AEM form field, which is stored persistently. When a higher-privileged user or site visitor later browses the page containing that field, the script executes in their browser under their session, enabling session/cookie theft or actions on their behalf. No public exploit code was identified, and successful exploitation still requires the victim to view the affected page (UI:R).