Adobe Experience Manager EUVD-2026-100547

Exploitation requires (1) a low-privilege authenticated foothold on the AEM instance (PR:L) and (2) a victim to actively visit an attacker-crafted webpage (UI:R) - both are explicit limiting factors that constrain real-world abuse. The flaw is a DOM-based sink, so the malicious data is processed client-side in the victim's browser rather than reflected by the server. Affected deployments are Adobe Experience Manager 6.5 up to and including 6.5.25; the description names no special non-default feature toggle, but the required privilege level and mandatory user interaction meaningfully reduce the realistic attack surface compared to the network vector alone.

This is a moderate-severity DOM-based XSS (CWE-79) in Adobe Experience Manager with a vendor-provided CVSS 3.1 base score of 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N). The signals are internally consistent and point to a bounded, non-critical issue rather than a top priority: network reachable (AV:N) and low complexity (AC:L), but it requires some privileges (PR:L) and victim interaction (UI:R), with only low confidentiality and integrity impact and no availability impact. The changed scope (S:C) is the one factor that elevates concern, reflecting that script executing in the victim's browser can affect resources beyond the vulnerable component. No EPSS score, CISA KEV listing, SSVC decision data, or POC was provided in the input, so there is no evidence of active exploitation or published exploit code - this reads as a theoretically exploitable but not-yet-weaponized flaw. The combination of required privileges plus required user interaction typically suppresses real-world exploitation probability, so despite the network vector this is better treated as a routine patch-cycle item than an emergency, absent any exploitation intelligence.

An attacker with low-level access to an AEM instance plants or references malicious input that is unsafely written into the DOM, then lures an authenticated victim (e.g., a content author or administrator) to visit a crafted page. When the victim's browser processes the manipulated DOM, attacker-controlled JavaScript executes in the victim's session context, potentially stealing session data or performing actions as that user. No public exploit code was identified at time of analysis.