Adobe Commerce CVE-2026-48413

A low-privileged account within the Adobe Commerce or Magento Open Source instance is required - CVSS PR:L confirms authentication is necessary, but only at the lowest privilege tier (e.g., a standard customer account). In most public storefronts, this is obtainable via self-registration with no additional barriers. The attacker must be able to submit input to at least one form field that is stored and subsequently rendered without proper output encoding in another user's browser context. Victim interaction is required (CVSS UI:R): a second user - ideally with elevated privileges such as a store administrator - must navigate to the page that renders the stored payload. Exploitation is limited by: the need for a valid account (disabling open registration reduces the unauthenticated attack surface), the mandatory victim page visit (no passive or drive-by exploitation path exists), and administrative review workflows that bring privileged users into contact with user-submitted content. No non-default configuration or specific platform mode is required - the vulnerability affects standard form field handling in default Commerce deployments.

The CVSS 8.7 High vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N) is internally consistent and credible for a stored XSS with scope change. AV:N and AC:L indicate no special network positioning or complex preconditions beyond holding a low-privileged account. PR:L is the primary exploitation constraint - an attacker must possess a valid low-privileged account in the Commerce instance. However, in most publicly accessible Commerce storefronts, customer self-registration is enabled by default, making this prerequisite trivially satisfied. UI:R requires that a victim - most valuably an administrator reviewing submissions - must actively browse to the page containing the injected payload; this is not a zero-click vector. The S:C/C:H/I:H combination is the most significant risk amplifier: if an administrator views the injected content, the attacker gains execution in the admin's browser context, potentially yielding full store control. No EPSS score was provided in the input data; no CISA KEV listing exists, and no POC has been identified. Real-world risk is elevated for stores with open customer registration and active admin review workflows, but is lower for private B2B deployments with controlled account provisioning.

An attacker registers a low-privileged customer account on an Adobe Commerce storefront and injects a JavaScript payload (e.g., a cookie-stealing script) into a vulnerable form field such as a product review, address attribute, or custom checkout field. When a store administrator later navigates to a backend page that renders the stored content - such as a customer management or order review screen - the script executes in the admin's browser, exfiltrates the admin session token to an attacker-controlled server, and grants the attacker full administrative control over the Commerce store. No public POC has been identified at time of analysis.