Drupal Webform EUVD-2026-107839

Exploitation requires an authenticated Drupal account that has been granted Webform privileges sufficient to create or edit webforms, elements, or related configuration (CWE-267: a role is permitted an unsafe action it should not be). It further requires user interaction (CVSS UI:R): a victim - typically an administrator or another higher-trust user - must view the page where the stored payload is rendered for the script to execute. Limiting factors: this is not remote-unauthenticated (PR:L), the payload only fires against users who view the affected output, impact is confined to confidentiality and integrity at Low with no availability impact, and the site must be running an affected Webform version (0.0.0 to before 6.2.12, or 6.3.0 to before 6.3.1). Sites restricting Webform authoring permissions to fully trusted staff substantially reduce exposure.

This is a genuinely moderate-priority issue rather than a critical emergency, and the signals are largely consistent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N, base 4.6 Medium) describes a network-reachable but privilege-gated stored XSS: PR:L means the attacker must already hold a valid account with permission to create or edit Webform content/elements, and UI:R means a victim must subsequently view the poisoned output for the payload to fire. The low-probability exploitation signals agree with this: EPSS is 0.19% (8th percentile), there is no CISA KEV listing, and no public exploit was identified in the provided data - so no public exploit identified at time of analysis. The vuln.today Decision label is 'this_month,' indicating a scheduled-patch urgency rather than act_now/emergency, which aligns with the low EPSS and absence of KEV. The CWE-267 classification (Privilege Defined With Unsafe Actions) is the key nuance: the real risk is a trust-boundary/privilege problem where a lower-trust role (e.g., a form builder or content editor) can store markup that executes in the session of higher-trust users such as administrators reviewing forms or submissions. No data is sharply conflicting; the main caveat is that the exact injection point (form element, submission field, or configuration surface) is not detailed in the available sources, so the trigger is not described in the available sources.

An attacker who already holds a Drupal account with Webform create/edit privileges embeds a malicious script into a webform element or configuration field. When an administrator or other higher-privileged user later views that form or its submissions in their browser, the stored script executes in their authenticated session, enabling actions such as session/cookie theft or performing admin actions on their behalf. No public exploit code was identified in the provided data.