Adobe Experience Manager EUVD-2026-100536

Exploitation requires an authenticated low-privileged account with the ability to submit input into the affected AEM form fields (PR:L), and the stored payload only triggers when a victim subsequently browses to the page rendering that field (UI:R). Limiting factors: attacker must already have valid authenticated access to the AEM authoring/form workflow, the malicious content must be persisted into a vulnerable field, and a victim must actively view the affected page for the script to execute - reducing the practical blast radius despite the network attack vector. Affected deployments are AEM 6.5 (≤6.5.25) and AEM 6.5 LTS (≤6.5 LTS SP3); other versions are not indicated as vulnerable.

This is a moderate-severity stored XSS (CVSS 5.4, CWE-79) whose signals align consistently toward LOW real-world urgency despite affecting a widely-deployed enterprise product. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) indicates network-reachable but authenticated (PR:L - low-privileged) exploitation requiring victim user interaction (UI:R), with only partial confidentiality and integrity impact and no availability impact; the changed scope (S:C) reflects that injected script executes in a victim's browser context distinct from the vulnerable AEM component. CISA's SSVC decision framework reinforces low priority: Exploitation=none, Automatable=no, Technical Impact=partial. No EPSS score was supplied in the input, and there is no KEV listing and no public POC, so all exploitation signals point the same direction with no conflict. The combination of required authentication, required user interaction, and the need to inject into specific form fields makes this a genuine but non-emergency patch item rather than a drop-everything priority - characteristic of an inflated-feeling but realistically limited stored XSS. No key signals contradict one another here.

A low-privileged authenticated AEM user (e.g., a content author or form contributor) injects malicious JavaScript into a vulnerable form field; the payload is stored server-side. When a higher-privileged user or site visitor later browses to the page rendering that field, the script executes in their browser, enabling session/token theft or actions in the victim's authenticated context. No public exploit code is identified at time of analysis, and successful exploitation depends on the victim actually viewing the affected page.