MEDIUM 5.4

CVE-2026-47973: Adobe Experience Manager Stored XSS Vulnerability

Adobe Experience Manager has a stored cross-site scripting (XSS) vulnerability that allows low-privileged users to inject malicious scripts into form fields. When other users view pages containing these compromised fields, the attacker's JavaScript executes in their browsers, potentially stealing credentials, session tokens, or sensitive data. The vulnerability affects multiple versions of AEM, including 6.5.24, LTS SP1, and 2026.04.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.4 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
Weaknesses (CWE)
CWE-79
Affected products
4 configuration(s)
Published / Modified
2026-06-09 / 2026-06-17

NVD description (verbatim)

Adobe Experience Manager versions 6.5.24, LTS SP1, 2026.04 and earlier are affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields. Malicious JavaScript may be executed in a victim's browser when they browse to the page containing the vulnerable field. Scope is changed.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

This is a stored XSS vulnerability (CWE-79) in Adobe Experience Manager that persists user-supplied input without proper sanitization in form field components. An authenticated attacker with low privileges can craft malicious payloads and inject them into vulnerable form fields. Because the vulnerability changes scope—affecting users beyond the attacker's authorization level—any authenticated user viewing a compromised form receives the malicious script execution in their browser context. The attack vector is network-based with low attack complexity, requiring user interaction (visiting the page) and low-privilege credentials.

Business impact

Compromised AEM instances can be weaponized by disgruntled employees or contractors to harvest data from higher-privileged users, including content editors, administrators, and other staff. This enables credential theft, unauthorized access to sensitive information, malware distribution through trusted channels, and potential lateral movement within enterprise networks. For organizations relying on AEM for public-facing content delivery, XSS injection could damage customer trust and expose visitor data.

Affected systems

Adobe Experience Manager 6.5.24, LTS SP1, and 2026.04 and earlier versions are confirmed affected. Organizations running these versions should inventory their AEM deployments immediately. Verify the exact version in your environment via the AEM System Information console or product documentation.

Exploitability

The vulnerability requires low-privilege authentication and user interaction (victim must visit the page), moderating real-world exploit likelihood in highly restricted environments. However, in organizations where content contributors or customer service representatives have AEM access, or in multi-tenant SaaS deployments, the risk is elevated. The CVSS score of 5.4 (Medium) reflects the authentication requirement and user-interaction constraint, but the scope change elevates concern—compromises affect users beyond the attacker's privilege level.

Remediation

Apply Adobe's security updates for Experience Manager as soon as they become available. Patch priority depends on the specific versions in your environment. Until patches are deployed, implement input validation and output encoding controls at the application level, restrict form field editing to high-trust personnel, and monitor for unauthorized form modifications. Content Security Policy (CSP) headers can provide defense-in-depth against JavaScript execution, though they are not a substitute for patching.

Patch guidance

Monitor Adobe's official security bulletin for Experience Manager patch releases corresponding to the affected versions (6.5.24, LTS SP1, 2026.04). Adobe typically releases cumulative patches; verify the exact patch version and compatibility with your deployment before applying. Test patches in a staging environment to confirm form functionality and any dependent integrations remain intact. Verify against the vendor advisory for exact upgrade paths, as AEM has multiple release branches.

Detection guidance

Monitor form field submissions and stored data for unexpected JavaScript keywords (script, onerror, onload, etc.) in fields that should contain only text or structured data. Review access logs for low-privileged accounts modifying form definitions or field content. Implement client-side scanning for inline event handlers in form elements. Correlate form modifications with user accounts to identify suspicious patterns. Use browser developer tools to inspect stored form HTML for embedded scripts.

Why prioritize this

Although the CVSS score is Medium (5.4), the scope change and authentication requirement make this a moderate risk for most organizations. Prioritize if: you operate a multi-tenant or public-facing AEM instance, have a large population of content contributors, or are in a regulated industry (healthcare, finance) where user data compromise carries compliance risk. For isolated, internally-managed AEM instances with restricted contributor access, this merits standard patch cycles rather than emergency response.

Risk score, explained

The CVSS 3.1 score of 5.4 reflects: network attack vector (AV:N), low attack complexity (AC:L), low privilege requirement (PR:L), required user interaction (UI:R), changed scope (S:C), and limited impact (confidentiality and integrity compromised, no availability impact). The score appropriately captures that an attacker needs valid credentials but can then affect users outside their privilege level. Real-world risk depends on your AEM user population and the sensitivity of data these users access.

Frequently asked questions

Do we need to patch immediately, or can this wait?

If your organization has strict role-based access control and limits form-editing privileges to a small, vetted team, this can follow standard patching windows. If content contributors are numerous or less trusted, or if your AEM instance is multi-tenant, prioritize patching within 30 days. The lack of KEV status (no known active exploitation as of the advisory date) provides some breathing room, but stored XSS is a common attack vector.

What is 'scope change' and why does it matter?

Scope change means the vulnerability allows an attacker to access resources or affect users beyond their normal privilege boundary. In this case, a low-privilege user (e.g., a contributor) can inject code that executes for higher-privileged users (e.g., editors or admins). This amplifies impact significantly, even though the CVSS base score is moderate.

Can a Content Security Policy prevent this attack?

CSP can block inline scripts and restrict script sources, providing a useful defense layer. However, CSP is not guaranteed to stop all XSS variants and should never replace patching. Use CSP as a complementary control: set a strict policy (script-src 'self'; object-src 'none') and monitor violations, but prioritize obtaining and testing patches from Adobe.

How do we find out which AEM version we are running?

Log into your AEM instance as an administrator, navigate to Tools > Operations > Web Console > System Information, or review the version file at /etc/system/version. Document all AEM instances (author, publish, and dispatcher nodes) and their exact version numbers before assessing patch applicability.

This analysis is based on the official vulnerability advisory and CVSS assessment as of the publication date. Patch availability, specific affected versions, and detailed remediation steps must be verified against Adobe's official security bulletin and your vendor documentation. SEC.co does not provide exploit code or weaponized proof-of-concept demonstrations. Organizations should validate patch applicability and test in non-production environments before deploying to production systems. Risk scoring is contextual; actual risk depends on your deployment architecture, user population, and data sensitivity. Source: NVD (public-domain), retrieved 2026-07-16. Analysis generated by SEC.co (claude-haiku-4-5).