Adobe Commerce EUVD-2026-99210

Exploitation requires the attacker to hold a valid low-privileged account on the Adobe Commerce / Magento Open Source instance (PR:L) and the ability to submit input into a specific vulnerable form field whose value is later rendered to other users without adequate output encoding. Successful payload execution additionally requires a victim (such as a store administrator or another user) to browse to the page containing the stored field (UI:R) - the script does not fire autonomously. Limiting factors: no unauthenticated exploitation is possible, victim interaction is mandatory, and impact is confined to confidentiality and integrity of the victim's browser session/account (A:N - no availability impact). This is most exploitable in multi-user or B2B deployments where low-privileged accounts are easily obtained.

This is a stored XSS flaw (CWE-79) in Adobe Commerce / Magento Open Source with a vendor CVSS 3.1 of 8.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N). The signals are mixed: the network vector (AV:N) and low complexity (AC:L) raise severity, and the changed scope (S:C) is what pushes this into the high band, since injected script executes in a victim's browser context - a different security authority than the vulnerable application. However, two real-world dampeners apply: exploitation requires an existing low-privileged account (PR:L), so the attacker must already be authenticated to the store, and it requires victim interaction (UI:R) - a privileged user must browse to the page containing the poisoned field. No EPSS score, CISA KEV entry, SSVC decision, or POC indicator was provided in the input, so exploitation probability and automatability cannot be quantified from the data at hand. Net assessment: a genuine priority for internet-facing Adobe Commerce storefronts (especially multi-tenant/B2B deployments where low-privileged accounts are common), but not a drop-everything unauthenticated RCE - the PR:L and UI:R prerequisites make this more suited to targeted account/session takeover than mass automated exploitation. EPSS and KEV data are MISSING and should be checked before final prioritization.

A low-privileged user (e.g., a customer, vendor, or junior admin account) submits malicious JavaScript into a vulnerable form field that is later rendered to other users. When an administrator or another victim later views the page containing that stored field, the script executes in their browser, allowing the attacker to hijack the victim's session or escalate to their account privileges. No public exploit code was identified at time of analysis; the attack requires both a valid low-privileged account and victim interaction (viewing the page).