Adobe Experience Manager EUVD-2026-100550

Exploitation requires an authenticated low-privileged account on Adobe Experience Manager (PR:L) with the ability to submit data into the affected form fields, plus a victim who subsequently browses to the page rendering the stored payload (UI:R). Affected builds are AEM 6.5 up to and including 6.5.25 and AEM 6.5 LTS up to and including SP3. The limiting factors - required authentication, required victim interaction, and the fact that impact is confined to script execution in a browser (no direct server confidentiality/integrity loss beyond the injected context) - reduce realistic risk; the exposure is greatest on author/multi-tenant instances where content-contributor accounts are not fully trusted.

This is a moderate-severity stored XSS (CWE-79) in Adobe Experience Manager, scored CVSS 5.4 by Adobe PSIRT. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) indicates network reach and low attack complexity, but two factors materially cap real-world risk: the attacker must already hold low-privileged authenticated access (PR:L), and a victim must browse to the page containing the injected field (UI:R). The scope change (S:C) reflects that injected script executes in the victim's browser context rather than only the vulnerable component, which is typical and expected for stored XSS. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence, so there is no evidence of active exploitation or weaponization - this appears to be a vendor-disclosed issue rather than an urgent in-the-wild threat. Net assessment: a legitimate but not emergency priority. It is more relevant for multi-tenant or author-instance AEM deployments where low-privileged content contributors are not fully trusted; in locked-down single-tenant author environments the authenticated + user-interaction prerequisites meaningfully reduce likelihood. Missing data to note explicitly: no EPSS probability and no KEV/POC signals were supplied, so exploitation likelihood cannot be quantified from the input.

A low-privileged authenticated user (e.g., a content contributor on an AEM author instance) injects malicious JavaScript into a vulnerable form field. The payload is stored, and when another user - such as a reviewer or administrator - browses to the page rendering that field, the script executes in their browser, potentially hijacking their session or performing actions in their context. No public exploit code was identified in the provided intelligence.