Drupal UI Patterns EUVD-2026-43079

Exploitation requires a valid, low-privileged Drupal account with permission to create or edit content that is processed by the UI Patterns (SDC in Drupal UI) module - specifically the component or field rendering path affected by insufficient output encoding. A separate victim user (potentially an administrator) must then view or interact with the page rendering the stored payload, making UI:R a hard prerequisite. Exploitation is limited to Drupal installations running the UI Patterns contributed module versions 2.0.0-2.0.16 (or up to 2.0.17 per NVD); sites not using this specific contributed module are unaffected. The attack does not apply to anonymous, unauthenticated submission scenarios unless the site explicitly grants anonymous users content authoring permissions.

The CVSS 3.1 score of 5.4 (Medium) accurately reflects the attack constraints: PR:L requires the attacker to hold at least a low-privileged account on the Drupal site, and UI:R means exploitation depends on a victim (potentially an administrator) navigating to a page rendering the malicious content. These requirements meaningfully limit opportunistic exploitation. The EPSS of 0.25% at the 17th percentile reinforces low observed exploitation activity, and no KEV listing or public POC is noted. The S:C (scope changed) metric is the key risk amplifier: a low-privileged contributor could craft a payload that, when viewed by an admin, leads to session token theft, privilege escalation, or administrative action hijacking - making the real-world impact higher than the base score alone suggests for sites with mixed contributor trust models. No conflicting signals exist between CVSS and other intelligence sources; this is a medium-severity, low-exploitation-probability issue that warrants timely patching rather than emergency response.

An authenticated Drupal site member with content creation privileges submits a UI Patterns component configuration or field value containing a crafted JavaScript payload. The malicious input is stored in the database. When an administrator navigates to the affected content for review or editing, the stored script executes in their browser, potentially stealing the session cookie and granting the attacker administrative access to the Drupal site.