Adobe Experience Manager CVE-2025-64549

Exploitation requires an authenticated account with at least low privileges in Adobe Experience Manager (6.5.23 or earlier, including AEM as a Cloud Service and 6.5 LTS) sufficient to submit or edit content in a vulnerable form field where input is not properly sanitized. The stored payload only fires when a victim user subsequently navigates to the page rendering that field (UI:R), so successful attack depends on a second user with access to the affected page viewing it. This limits impact to environments where multiple users share content workflows; a single-user or tightly-restricted authoring setup, or configurations without the vulnerable form fields exposed, materially reduce exploitability. No unauthenticated or zero-interaction path exists.

This is a genuinely low-priority issue despite affecting a widely-deployed enterprise CMS. The CVSS 3.1 base score is 5.4 (Medium), and every signal points to limited real-world risk. The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N shows the attack is doubly gated: it requires an authenticated low-privileged attacker (PR:L) to plant the payload AND requires a victim to browse to the affected page (UI:R). Impact is only C:L/I:L (script execution in a single victim's browser session), with no availability impact. EPSS reinforces low urgency at 0.25% (15th percentile), meaning exploitation is statistically unlikely relative to the broader CVE population. There is no CISA KEV listing and no public exploit code identified. There are no conflicting signals here - CVSS, EPSS, and the description agree this is a stored XSS requiring authenticated injection plus victim interaction, which is the correct low-to-medium band. The main caveat is scope: as one of several near-identical stored/DOM XSS issues in the same Adobe bulletin (APSB25-115), it should be patched in aggregate rather than triaged individually, but it does not warrant emergency handling on its own.

A low-privileged authenticated AEM user (e.g., a content author or form editor) injects a malicious JavaScript payload into a vulnerable form field. When another user - such as an administrator or another content contributor - later browses to the page containing that field, the stored script executes in their browser session, potentially enabling session/cookie theft or actions in the victim's context. No public exploit code has been identified at time of analysis.