Adobe Experience Manager CVE-2026-110037

Exploitation requires an authenticated account with at least low privileges in Adobe Experience Manager (PR:L) - specifically the ability to submit or edit content in affected form fields - so anonymous external exploitation is not possible. Execution additionally requires victim interaction (UI:R): a separate user must browse to the page rendering the stored, unsanitized field before the injected JavaScript runs. Affected deployments are AEM 6.5 up to and including 6.5.25 and AEM 6.5 LTS up to SP3; environments already patched per APSB26-152 or on later builds are not vulnerable. Risk is highest in multi-author, multi-tenant, or externally-facing content-authoring setups where low-trust accounts can inject content consumed by higher-privileged users or site visitors.

This is a moderate-severity stored XSS (CVSS 5.4, CWE-79) with signals that point to real but bounded risk. The provided CVSS vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) indicates network-reachable, low-complexity exploitation but requires an authenticated low-privileged account (PR:L) AND victim interaction (UI:R), both of which dampen mass-exploitation potential. Scope is changed (S:C), reflecting that injected script executes in a victim's browser context distinct from the vulnerable AEM component - the classic stored-XSS scope shift that justifies the elevated-over-baseline score. No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input, so exploitation probability cannot be quantified from these sources; absence of KEV/POC is not evidence of safety but does argue against widespread automated exploitation today. The vendor (Adobe PSIRT) reported and patched this (APSB26-152), which is consistent with responsible disclosure rather than observed in-the-wild abuse. Net: a legitimate patch-management priority for AEM operators - especially multi-author/multi-tenant deployments - but not an emergency drop-everything issue absent any exploitation evidence. No conflicting signals were detected between the CVSS vector and the description; both agree on authenticated input with victim-triggered execution.

A low-privileged AEM author or form contributor submits a form field containing malicious JavaScript, which is stored and later rendered unsanitized. When a higher-privileged user or site visitor browses the page containing the tainted field, the script executes in their browser, enabling session/cookie theft or actions performed as the victim. No public exploit code was identified in the provided data, but stored XSS in CMS form fields is a well-understood, low-complexity technique.