Adobe Experience Manager EUVD-2026-44383

Exploitation requires possession of a valid low-privileged account on the target AEM instance with write access to content form fields (PR:L per CVSS vector). The attacker must be able to submit content through the AEM authoring interface in order to store the XSS payload. A separate victim user with a browser session must subsequently load the page containing the injected content (UI:R), meaning the attack cannot be fully automated end-to-end. Limiting factors include: the authentication barrier (even at low privilege level), the requirement for victim interaction, the SSVC confirmation that the attack is not automatable, and the network accessibility of AEM authoring endpoints typically being restricted to internal or VPN-connected users in hardened deployments. No non-default configuration is required - any multi-user AEM deployment where low-privileged authors can submit form content is potentially exposed.

CVSS scores this at 5.4 Medium with vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N. The network attack vector and low complexity are consistent with a web-based stored XSS, but PR:L confirms the attacker must hold a valid low-privileged account, and UI:R means a separate victim must load the page - both are meaningful friction points. The scope change elevates the score by reflecting cross-boundary impact. EPSS at 0.29% (21st percentile) is low, indicating the broader exploitation community has not moved on this class of vulnerability in AEM at the time of scoring. SSVC reinforces this: exploitation status is none, the attack is not automatable, and technical impact is only partial. There is no CISA KEV listing and no reported POC. The overall picture is consistent: this is a genuine vulnerability warranting patching on a standard cadence, but it does not represent an emergency zero-day scenario requiring immediate emergency response outside normal patch windows.

A low-privileged AEM content author injects a crafted JavaScript payload into a vulnerable form field within the AEM authoring interface; the payload is stored server-side and renders into page HTML. When an AEM administrator or other privileged user subsequently navigates to the affected content page, the script executes in their browser session, potentially harvesting session tokens or silently performing actions under their identity. No public exploit code has been identified at time of analysis, but the technique is well understood and operationally straightforward for any attacker with AEM author credentials.