Adobe Experience Manager CVE-2026-48260

The attacker must hold a valid low-privileged authenticated session in Adobe Experience Manager (confirmed by CVSS PR:L) - unauthenticated exploitation is not possible. A victim with an active AEM browser session must actively visit or interact with an attacker-controlled crafted URL or DOM-injectable page fragment (CVSS UI:R). The changed scope (S:C) means the injected script executes in the victim's browser context, crossing into resources outside the AEM application's own origin. Exploitation is not automatable per SSVC, which rules out scripted mass-targeting without victim interaction. Limiting factors: attacker must be a provisioned AEM user; victim must perform active user interaction while authenticated; no path to exploitation from an anonymous or network-adjacent unauthenticated position exists based on available data.

The CVSS 3.1 score of 5.4 (Medium) reflects low attack complexity and network delivery (AV:N/AC:L), but is constrained by required low-privilege authentication (PR:L) and mandatory user interaction (UI:R). The changed scope (S:C) elevates the score modestly by acknowledging that injected JavaScript executes in the victim's browser beyond the AEM application boundary, potentially harvesting credentials or session tokens. Real-world risk signals are consistently subdued: EPSS at 0.27% places this vulnerability in the 19th percentile of exploitation likelihood, indicating the security community observes very little attacker interest; SSVC confirms no observed exploitation and no automatable attack path, ruling out worm-like or mass-scale campaigns. No public POC has been identified from any referenced source. The PR:L requirement is a genuine gatekeeping factor in enterprise AEM deployments where author/editor account provisioning is controlled. Cross-referencing CVSS and SSVC, this is a real but medium-priority finding - meaningful for environments with contested internal trust boundaries (e.g., multi-tenant AEM instances, external contributors), but not an emergency patch for air-gapped authoring environments.

An attacker with a low-privileged AEM account (such as a content contributor or external agency editor) crafts a URL containing a DOM-manipulating payload targeting an unsanitized sink in the AEM authoring interface. The attacker delivers this link to a higher-privileged victim - an AEM administrator - via email or an in-platform notification, who clicks it while authenticated. The victim's browser executes the injected JavaScript, exfiltrating the session cookie or silently performing administrative actions on the attacker's behalf within AEM. No public proof-of-concept has been identified at time of analysis.