Adobe Commerce EUVD-2026-99211

Exploitation requires the attacker to inject a persistent JavaScript payload into a vulnerable Adobe Commerce form field, and then requires a victim to subsequently browse to the page that renders that stored field (UI:R - victim interaction is a hard prerequisite, so this cannot fire fully automatically). The vendor vector marks the injection step as unauthenticated (PR:N), but stored XSS into form fields in Commerce/Magento commonly implies the attacker can reach a form whose contents are persisted and re-displayed; verify with Adobe whether the affected form is customer-facing/public or requires an account. Limiting factors: dependency on a victim visiting the affected page, and applicability only to the affected Adobe Commerce, Adobe Commerce B2B, and Magento Open Source versions.

This is a genuinely high-priority flaw by severity signals but with important caveats on real-world exploitation. The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N, 9.3) describes a network-reachable, low-complexity, unauthenticated stored XSS with a scope change and high confidentiality/integrity impact - a serious profile for an e-commerce platform. However, several exploitation signals are MISSING from the input: there is no EPSS probability, no CISA KEV listing, and no POC/exploit-code indicator. Per precision rules, exploitation status is therefore 'no public exploit identified at time of analysis.' One point warrants vendor verification: the vector asserts PR:N (unauthenticated), yet stored XSS 'injected into vulnerable form fields' frequently requires at least low-privileged access (a customer or admin account) to reach the persistent storage point - this PR:N-versus-typical-stored-XSS tension should be confirmed against Adobe APSB26-153. Net: treat as a high-value patch target given Adobe Commerce's exposure and the scope-change account-takeover potential, but the absence of KEV/EPSS/POC suggests no evidence of active mass exploitation yet, so this is urgent-patch rather than emergency-incident priority.

An attacker submits a crafted JavaScript payload into a vulnerable Adobe Commerce form field, where it is stored persistently. When a victim (e.g., a store admin or another user) later browses to the page rendering that field, the script executes in their browser, enabling session theft or actions performed as the victim. No public exploit code was identified in the provided data.