Adobe Experience Manager CVE-2025-64613

Exploitation requires the attacker to hold a low-privileged authenticated account in Adobe Experience Manager with the ability to edit/submit content into form fields (PR:L), making this an authenticated stored-XSS rather than an anonymous attack. Execution is further gated by required victim user interaction (UI:R): a separate user must browse to the page rendering the attacker-controlled field before the stored JavaScript runs in their browser. Impact is bounded to Low confidentiality and Low integrity with no availability effect; the scope change (S:C) reflects code crossing from the AEM application into the victim's browser context. Affected deployments include AEM 6.5.23 and earlier, 6.5 LTS, and AEM Cloud Service per the CPE data.

This is a moderate-severity stored XSS (CVSS 5.4) whose signals consistently point to a lower-priority, non-urgent issue rather than a critical one. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) requires an authenticated low-privileged attacker to inject the payload AND a victim to subsequently browse the affected page (UI:R), with only Low confidentiality/integrity impact and no availability impact - the scope change (S:C) reflects script execution crossing into the victim's browser context. The EPSS score is very low (0.22%, 12th percentile), indicating little likelihood of broad exploitation activity. There is no CISA KEV listing and no public proof-of-concept identified, so exploitation status is 'no public exploit identified at time of analysis.' All signals are consistent (no conflicts): low EPSS, no KEV, no POC, authenticated-plus-user-interaction prerequisite, and bounded impact all agree this is a real-but-low-priority hardening fix rather than an emergency. The one amplifying factor is that AEM is a widely deployed enterprise platform, so the aggregate attack surface is large even if per-instance risk is modest.

A low-privileged authenticated AEM user (e.g., a content author or form editor) injects malicious JavaScript into a vulnerable form field, which is stored persistently. When an administrator or other victim later browses the page rendering that field, the script executes in their browser session, potentially enabling session theft or actions in the victim's context. No public exploit code is known, and successful attack requires both authenticated injection access and a victim visiting the page.