Adobe Experience Manager CVE-2025-64827

Exploitation requires an authenticated low-privileged AEM account (PR:L) with the ability to submit content into an affected form field, and it is stored/persistent - the payload fires only when a victim subsequently navigates to the page rendering that unsanitized field (UI:R). It is therefore not exploitable pre-auth or against a passive target without victim page-visit interaction. Affected deployments are AEM 6.5.23 and earlier, including AEM Cloud Service and AEM 6.5 LTS. Limiting factors: two required conditions (attacker authentication plus victim browsing) and impact confined to the victim's browser context with only low confidentiality/integrity effect.

This is a genuinely low-priority issue despite being a network-vector XSS. The CVSS 3.1 base score of 5.4 (MEDIUM) is honestly rated: AV:N is offset by two independent gates - PR:L (the attacker must already hold a low-privileged authenticated AEM account able to write to form fields) and UI:R (a victim must browse to the page hosting the injected field). Impacts are capped at C:L/I:L/A:N, and while S:C reflects the browser-context scope change typical of XSS, no OS-level or data-store compromise results. Corroborating signals all point down: EPSS is 0.20% (9th percentile), there is no CISA KEV listing, and no public POC is referenced. No SSVC record is provided; inferring from the data, exploitation would be 'none', automatable 'no' (requires per-instance authenticated injection plus victim interaction), and technical impact 'partial'. No signals conflict - every source (low EPSS, no KEV, no POC, double-gated vector) agrees this is a low-real-risk hardening fix rather than an active threat. The only elevating factor is AEM's enterprise footprint, which raises worst-case blast radius but not likelihood.

A low-privileged AEM author or form-content contributor injects a malicious <script> payload into a vulnerable form field that is not properly sanitized. When a higher-privileged user or site visitor later browses the page containing that field, the stored JavaScript executes in their browser session, potentially enabling session-token theft or actions in the victim's authenticated context. No public exploit code is identified, and successful execution depends on the victim actually visiting the affected page.