Adobe Experience Manager CVE-2025-64872

Exploitation requires an attacker to already hold a HIGH-privileged AEM account (author/administrator, PR:H) capable of writing to the vulnerable form fields, and requires a victim to subsequently browse to the page rendering the injected field (UI:R). Affected deployments are AEM 6.5.23 and earlier, including AEM Cloud Service and AEM 6.5 LTS. This is not remotely exploitable by anonymous or low-privilege users - the privilege prerequisite plus required victim interaction substantially limit realistic exploitation to insider-threat or compromised-admin situations.

This is a genuinely low-priority issue despite the enterprise footprint of Adobe Experience Manager. The CVSS 3.1 base is 4.8 (Medium) with vector AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N - every mitigating factor is present: it requires HIGH privileges (PR:H, an admin/author-level account already trusted to publish content), it requires victim user interaction (UI:R, someone must browse to the page with the injected field), and the impact is limited to C:L/I:L with no availability impact. EPSS is 0.21% (10th percentile), signaling very low predicted exploitation probability. There is no CISA KEV listing and no public POC identified. All signals are consistent and point the same direction: high-privilege-gated, click-gated, low-impact stored XSS. The only reason it registers at all is that scope is changed (S:C), reflecting script execution crossing into the victim's browser security context. No signals conflict; nothing suggests this warrants priority patching outside of normal Adobe quarterly maintenance (APSB25-115). Note the PR:H here is materially weaker than its many PR:L sibling CVEs in the same bulletin - the attacker must already hold a highly privileged AEM account, further shrinking realistic risk.

A high-privileged AEM author or administrator injects malicious JavaScript into a vulnerable form field; the payload is stored server-side. When another user (e.g., a reviewer or site visitor) later browses to the page rendering that field, the script executes in their browser, enabling session-context actions such as cookie/token theft or UI redress. No public exploit code is known, and the attacker must already possess elevated privileges, making this largely an insider or compromised-admin scenario.