CVE-2026-47954: Adobe Experience Manager XSS Vulnerability

CVE-2026-47954 Overview

CVE-2026-47954 is a stored Cross-Site Scripting (XSS) vulnerability affecting Adobe Experience Manager (AEM) versions 6.5.24, LTS SP1, 2026.04, and earlier releases. A low-privileged authenticated attacker can inject malicious JavaScript into vulnerable form fields. The injected script executes in a victim's browser when they navigate to a page rendering the affected field. The flaw maps to CWE-79 and carries a changed scope, allowing impact beyond the initially vulnerable component. Adobe published advisory APSB26-56 documenting the issue and remediation guidance.

Critical Impact
Authenticated attackers with low privileges can persist malicious scripts that execute in any visitor's browser session, enabling session theft, content manipulation, and cross-component impact through the changed CVSS scope.

Affected Products

Adobe Experience Manager 6.5.24 and earlier
Adobe Experience Manager LTS SP1 and earlier
Adobe Experience Manager Cloud Service release 2026.04 and earlier

Discovery Timeline

2026-06-09 - CVE-2026-47954 published to the National Vulnerability Database
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-47954

Vulnerability Analysis

The vulnerability resides in how Adobe Experience Manager processes user-supplied content submitted through form fields. AEM stores the attacker-controlled payload server-side and later renders it without sufficient output encoding. When a victim loads the affected page, the browser parses and executes the embedded JavaScript in the context of the AEM origin.

Because the CVSS scope is changed, the executed script can affect resources or components beyond the security boundary of the vulnerable form. This includes administrative interfaces, author instances, and embedded iframes rendered alongside the malicious payload. User interaction is required because a victim must browse to the page that contains the stored payload.

The issue is classified under CWE-79, Improper Neutralization of Input During Web Page Generation. Exploitation does not require elevated privileges, only an authenticated session with permission to submit form content.

Root Cause

The root cause is missing or insufficient output encoding when rendering form field data back into HTML. AEM accepts script-bearing input on submission and stores it without neutralization, then serializes it into the response without contextual escaping. Standard HTML, attribute, and JavaScript-context encoding routines are not consistently applied to the affected sink.

Attack Vector

An attacker authenticates to AEM with low privileges sufficient to edit or submit form content. The attacker injects a JavaScript payload into a vulnerable field, typically using <script> tags or event handler attributes such as onerror and onload. The payload is persisted in the AEM repository. When an author, administrator, or end user loads the page rendering the field, the browser executes the script under the AEM origin, allowing the attacker to read cookies accessible to script, perform actions on behalf of the victim, or pivot to adjacent components via the changed scope.

No verified public exploit code is available. Refer to the Adobe Experience Manager Security Bulletin APSB26-56 for vendor technical details.

Detection Methods for CVE-2026-47954

Indicators of Compromise

Form field values in the AEM repository containing <script>, javascript:, or event-handler attributes such as onerror=, onclick=, and onload=
Unexpected outbound requests from author or publish instances to attacker-controlled domains immediately after a page load
Author or administrator sessions performing actions inconsistent with their normal workflow patterns shortly after viewing user-submitted content

Detection Strategies

Scan AEM JCR nodes and form submission stores for HTML and JavaScript syntax in fields expected to contain plain text
Review Dispatcher and web server access logs for requests to pages containing user-submitted form content followed by anomalous client-side requests
Inspect Content Security Policy violation reports for inline script execution on AEM-served pages

Monitoring Recommendations

Enable and centralize AEM audit logging for content modifications to form components and user-submitted fields
Monitor authenticated low-privilege accounts for unusual content submission volumes or payloads containing HTML markup
Alert on browser telemetry indicating script execution from AEM origins targeting session cookies or authentication endpoints

How to Mitigate CVE-2026-47954

Immediate Actions Required

Apply the security updates referenced in Adobe Security Bulletin APSB26-56 to all AEM 6.5, LTS, and Cloud Service deployments
Audit existing form submissions and stored content for previously injected script payloads and remove them before patching
Restrict low-privileged accounts that do not require form submission rights and review group memberships granting content authoring permissions

Patch Information

Adobe addressed CVE-2026-47954 in the updates documented in advisory APSB26-56. Upgrade Adobe Experience Manager 6.5 to the version released after 6.5.24, apply the LTS service pack released after LTS SP1, and move Cloud Service tenants to the release following 2026.04. Consult the vendor advisory for exact target versions and download links.

Workarounds

Deploy a strict Content Security Policy that disallows inline scripts and restricts script sources to trusted origins on AEM-served pages
Enforce server-side input validation and output encoding using the AEM XSS API (org.apache.sling.xss.XSSAPI) on all custom form components until patching is complete
Place a Web Application Firewall in front of AEM Dispatcher to block submissions containing HTML or JavaScript syntax in fields that should accept plain text

bash

# Example HTL output encoding for form field rendering in AEM
# Use context-appropriate display contexts to neutralize stored scripts
# Plain text context:
${properties.userInput @ context='text'}

# HTML attribute context:
<div title="${properties.userInput @ context='attribute'}"></div>

# Verify XSS protection filter is enabled in the Sling configuration:
# /system/console/configMgr/org.apache.sling.xss.impl.XSSFilterImpl