Adobe Experience Manager CVE-2026-48262

The attacker must hold a low-privileged authenticated account within the target AEM instance, as confirmed by CVSS PR:L. The victim must actively visit or be redirected to a specifically crafted URL or page - passive exposure is insufficient (CVSS UI:R; SSVC Automatable: no). The vulnerability operates entirely client-side via DOM manipulation, so no special AEM server-side configuration is required beyond a standard deployment. Exploitation is bounded by these two hard prerequisites: attacker credential access (limits opportunistic external exploitation) and victim browser interaction (prevents automated scanning-style attacks). Deployments that restrict AEM access to VPN-authenticated internal users are significantly harder to exploit because the PR:L credential prerequisite is more difficult for an external attacker to satisfy.

The vendor-assigned CVSS 3.1 score of 5.4 Medium is internally consistent: network reachable (AV:N), low complexity (AC:L), but gated by a credential requirement (PR:L) and mandatory victim interaction (UI:R), which together substantially constrain real-world exploitability. All independent risk signals align and reinforce this moderate assessment. EPSS at 0.27% (19th percentile) indicates that automated exploitation is not occurring and is not anticipated in the near term. SSVC rates exploitation as 'none,' technical impact as 'partial,' and automatable as 'no,' ruling out scanner-driven or worm-like mass exploitation. There is no CISA KEV listing and no public POC referenced in any source. The primary real-world risk concentration is in AEM deployments that permit low-trust external parties to authenticate - partner portals, self-registration workflows, or customer-facing AEM instances - where the PR:L barrier is more easily cleared. Internal-only deployments with controlled user bases face meaningfully lower residual risk after patching is prioritized. No conflicting signals were identified; this appears to be a credible Medium-priority issue with no elevation factors present at time of analysis.

An attacker holding a low-privilege AEM account (e.g., obtained through credential stuffing, phishing, or a self-registration portal) crafts a URL targeting an AEM page where a DOM source such as a URL hash or query string is unsafely written into the page by client-side JavaScript. The attacker delivers this URL to a target AEM user via email or a shared link, and when the victim opens it in their authenticated browser session, the injected script executes, potentially exfiltrating session cookies or performing content modifications within the AEM context. No public proof-of-concept code has been identified at time of analysis, and the requirement for victim interaction (UI:R) means delivery depends entirely on social engineering.