Adobe Experience Manager CVE-2026-106630

Exploitation requires (1) the ability to submit/persist input into a vulnerable AEM form field so the malicious script is stored, and (2) a victim subsequently browsing to the page that renders that field (UI:R - victim interaction is mandatory). The flaw affects AEM 6.5 LTS (up to and including SP3) and AEM 6.5 (up to and including 6.5.25); instances on patched builds per APSB26-152 are not affected. Limiting factors: the attack is not fully hands-off because it depends on a victim loading the poisoned page, and although the vendor rates it PR:N, in practice the injection step may require access to a form-authoring or form-submission surface - public-facing authoring/preview instances raise exposure while locked-down, internal-only authoring environments reduce it.

This is a stored (persistent) XSS in Adobe Experience Manager carrying a vendor CVSS 3.1 of 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N), driven largely by the scope change (S:C) and high confidentiality/integrity impact on the victim's session. The exploitation signals are notably thin: there is no EPSS score, no CISA KEV listing, and no public proof-of-concept in the provided data - so the current status is 'no public exploit identified at time of analysis'. The high base score reflects potential impact, not demonstrated real-world exploitation, so this should be treated as a patch-promptly item rather than an emergency drop-everything issue. One point of tension to verify: the vendor marks PR:N (unauthenticated), yet stored XSS 'injected into vulnerable form fields' in AEM commonly requires some authenticated content-authoring or form-submission capability to persist the payload - the privilege required for the INJECTION step is not clearly established by the description and should be confirmed with Adobe advisory APSB26-152. Note also that UI:R means a victim must load the affected page, which modestly limits automated, hands-off exploitation. Overall: credible, high-impact web vulnerability in a widely-deployed enterprise CMS, worth prioritizing on exposed/authoring instances, but without evidence of active or automated exploitation at this time.

An attacker stores crafted JavaScript inside a vulnerable AEM form field so the payload is persisted on the server. When a victim (e.g., a content reviewer, administrator, or another user) later browses to the page rendering that field, the script executes in their browser context, letting the attacker hijack the session or act with the victim's elevated privileges. No public exploit code is identified at this time, and exploitation requires the victim to view the poisoned page (UI:R).