Adobe Experience Manager CVE-2025-64585

Exploitation requires an authenticated low-privileged AEM account (PR:L) with the ability to submit data into the affected form field - this is an operator/authoring-dependent flaw, not an unauthenticated internet-facing one. The payload is stored, but execution is gated on a victim later browsing to the page that renders the vulnerable field (UI:R), meaning no code runs until a separate user views the content. Limiting factors that reduce real-world risk: the attacker must first obtain valid credentials with form-authoring capability, the target must visit the poisoned page, and impact is confined to Low confidentiality/integrity in the victim's browser session. Affected deployments are AEM 6.5.23 and earlier, including AEM 6.5 LTS and AEM Cloud Service per the CPE data.

This is a stored XSS flaw with a moderate CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N), and the aggregate signals consistently point to this being a lower-tier priority rather than an emergency. The CVSS vector requires low privileges (PR:L) and victim user interaction (UI:R), which caps impact to Low confidentiality and Low integrity with no availability effect; the scope change (S:C) reflects that injected script executes in the victim's browser context rather than only on the AEM server. EPSS is low at 0.25% (15th percentile), indicating a low modeled probability of exploitation in the near term, and this aligns with the absence of a CISA KEV listing and the absence of any identified public exploit. There is no conflict between the signals here - low EPSS, no KEV, no POC, authenticated precondition, and required user interaction all reinforce a non-urgent posture. The main mitigating factors that temper the risk are the authentication requirement (a low-privileged account is still needed to inject the payload) and the dependency on a victim subsequently browsing the affected page. The primary aggravating factor is that stored XSS persists server-side, so a single injection can affect many victims over time, and AEM is a high-value enterprise CMS where authors and administrators are attractive session-hijacking targets. Overall this is a legitimate but routine-severity vulnerability best handled on a standard patch cycle.

A low-privileged user with authoring access to an AEM instance submits a crafted payload into a vulnerable form field, persisting malicious JavaScript in the content repository. When a higher-privileged author or administrator later browses the page rendering that field, the script executes in their authenticated browser session, enabling session token theft or actions performed as the victim. No public exploit code has been identified at time of analysis, and exploitation requires both a valid low-privileged account and the victim viewing the page.