Drupal Commerce Core EUVD-2026-43115

Exploitation requires an authenticated Drupal user account with at minimum low-level privileges (PR:L per CVSS vector) - such as a registered customer or contributor role - capable of submitting input to a Commerce Core form field that is stored and later rendered without output encoding. A second condition is that a separate user (the victim, typically with higher privileges such as a site administrator) must navigate to and view the page containing the stored payload (UI:R per CVSS vector). Exploitation is limited by the requirement for two distinct actors: the injecting attacker and the browsing victim. Sites that restrict Commerce Core form access to fully trusted roles only, or that require administrator approval before account creation, significantly reduce the practical attack surface. Affects only Commerce Core 3.3.0 through 3.3.5; sites running 3.3.6 or later are not affected.

The CVSS 5.4 Medium score reflects a realistic but bounded threat: PR:L requires an authenticated session (a registered customer or low-privilege contributor), and UI:R demands that a second user - potentially an administrator - must view the poisoned page before the payload fires. These two prerequisites materially reduce the attack surface compared to unauthenticated stored XSS. The EPSS score of 0.16% at the 6th percentile strongly indicates this vulnerability has not attracted automated exploitation tooling and is not being mass-exploited. There is no CISA KEV listing and no publicly confirmed proof-of-concept code, reinforcing the low urgency signal from EPSS. The S:C and dual C:L/I:L impact ratings are consistent with session theft or form manipulation capabilities but fall short of full system compromise. In practice, the highest risk scenario is a malicious customer account targeting site administrators browsing order or product management views. Overall, this is a moderate-priority issue for Drupal Commerce sites - patch it promptly, but it is not an emergency requiring emergency change control.

An attacker registers or compromises a low-privilege Drupal customer account on a Commerce-enabled site and submits a crafted JavaScript payload (e.g., a cookie-stealing script) into a Commerce Core input field such as a product review, order note, or custom field. The payload is stored in the database and later rendered unescaped when a site administrator reviews orders or manages content in the Drupal backend, causing the script to execute in the administrator's browser and exfiltrating their session cookie to an attacker-controlled endpoint. No public proof-of-concept exploit has been confirmed at time of analysis.