Adobe Commerce EUVD-2026-99217

Exploitation requires (1) an attacker-reachable Adobe Commerce/Magento form field that persists attacker input, and (2) UI:R - a victim (admin or shopper) must subsequently browse to the page that renders the stored payload, at which point the script executes automatically. Limiting factors: the attack is not self-contained - it depends on a second victim visiting the affected page, and realistically depends on the attacker being able to write to the specific vulnerable field (the vendor's PR:N implies a publicly reachable form, but stored XSS commonly needs at least a low-privileged account, which should be confirmed against APSB26-153). Impact is bounded to confidentiality and integrity of the victim's session/account (A:N - no availability impact).

Vendor-provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N) rates this 9.3 Critical, driven largely by the scope change (S:C) and high confidentiality/integrity impact typical of a cross-site scripting flaw. However, the signals are thin and partly conflicting: no EPSS probability, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or imminent widespread exploitation to corroborate the critical score. The PR:N (unauthenticated) rating also sits uneasily with the mechanics of a STORED XSS into 'form fields' - storing a persistent payload in Adobe Commerce usually requires at least a low-privileged account or a publicly writable form, which is a meaningful caveat defenders should verify against the specific vulnerable field. Net: this is a genuinely high-priority flaw for internet-facing Adobe Commerce/Magento storefronts because of its scope-changing account/session-takeover potential and the platform's exposure, but in the absence of KEV/EPSS/POC signals it is better characterized as a high-severity patch-promptly issue than a confirmed under-active-attack emergency. Verify the exact affected form and privilege prerequisite via Adobe APSB26-153 before de-prioritizing.

An attacker submits crafted JavaScript into a vulnerable Adobe Commerce form field so the payload is persistently stored. When an administrator or another shopper later views the page rendering that field, the script executes in their browser, letting the attacker hijack the session, steal authentication tokens, or perform actions as the victim (a scope change beyond the attacker's own context). No public exploit code was identified at time of analysis, so weaponization effort is currently unknown.