Adobe Commerce CVE-2026-48371

Exploitation requires the attacker to possess a valid low-privileged authenticated account on the Adobe Commerce, Magento Open Source, or B2B installation with write access to at least one form field that is subsequently rendered in a browser without output encoding - confirmed by CVSS PR:L. A victim with elevated privileges (e.g., store administrator) must then navigate to the page containing the injected field while authenticated - confirmed by CVSS UI:R. Exploitation is not automatable per SSVC assessment, meaning each victim must independently visit the compromised page. Limiting factors include: the requirement for a pre-existing authenticated low-privileged account (eliminates fully unauthenticated attackers), the need for victim interaction (eliminates automated mass exploitation), and the restriction of impact to confidentiality and integrity (no availability impact). Environments that enforce strict role-based access controls limiting write access to form fields, or that restrict the admin panel to trusted networks, substantially reduce realistic risk beyond the raw CVSS score.

The CVSS 3.1 score of 5.4 (Medium) captures network reachability (AV:N), low attack complexity (AC:L), requirement for a low-privileged account (PR:L), required victim interaction (UI:R), and changed scope (S:C) with limited confidentiality and integrity impact and no availability impact. EPSS at 0.29% (21st percentile) indicates a low probability of automated exploitation in the near term. SSVC corroborates this: exploitation is rated 'none,' the attack is not automatable, and technical impact is only 'partial.' There is no CISA KEV listing and no known public proof-of-concept at time of analysis. The stored nature of the XSS and the S:C scope change meaningfully elevate practical impact compared to reflected variants - a single injected payload persists and affects every subsequent visitor without further attacker involvement. However, the PR:L prerequisite (an authenticated low-privileged account) and UI:R (victim must browse to the affected page) materially constrain the attacker pool and prevent fully unauthenticated or automated mass exploitation. On balance, this is a genuine but non-emergency priority: patch at the next scheduled maintenance window, with immediate action warranted only in environments where untrusted low-privileged users have write access to Commerce admin fields.

A low-privileged Commerce user - such as a content editor, restricted merchant, or B2B company admin - submits a crafted JavaScript payload into a vulnerable form field such as a CMS block, product attribute, or webhook configuration entry. The payload is persisted to the database and rendered without encoding when a store administrator later opens the affected page in their browser, causing the script to execute in the admin's session context, potentially exfiltrating their session token or silently performing privileged actions. No public proof-of-concept has been identified at time of analysis, but the attack requires only basic XSS knowledge and a legitimate low-privileged account.