Drupal Webform EUVD-2026-107838

Exploitation requires an authenticated low-privilege actor (PR:L) who can inject input into a Webform field or configuration that Drupal Webform later renders without proper HTML neutralization (CWE-79), plus a victim who views the rendered page (UI:R) - the stored payload does not fire on its own. The affected product is Drupal's Webform contrib module in versions 0.0.0 up to (not including) 6.2.12 and 6.3.0 up to (not including) 6.3.1. Limiting factors: the attacker must hold an account with content/form-submission rights, a separate user must load the poisoned page for the script to execute, impact is confined to the victim's browser session with unchanged scope (S:U) and no availability effect, and the specific field, form mode, or configuration that triggers the flaw is not described in the available sources.

This is a moderate-severity stored XSS (CVSS 4.6) that the signals consistently rate as a measured, non-emergency priority rather than a critical threat. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N shows network reach but three real brakes: low-privilege authentication (PR:L), required victim interaction (UI:R), and only Low confidentiality/integrity impact with no availability effect and unchanged scope. These line up with the other signals: EPSS is very low at 0.20% (10th percentile), there is no CISA KEV listing, and the vuln.today decision label is 'this_month' - a scheduled-patch urgency, not act_now or emergency. No conflicting signals are present; every source points the same direction. The main caveat is mechanism: the description states only that the flaw 'allows Stored XSS' and does not say which field, form configuration, or viewing context triggers it, so the exact attack surface is not described in the available sources. Bottom line - a genuine vulnerability worth patching on a normal cycle, not a drop-everything issue, consistent with the 'this_month' decision label.

An attacker with a low-privilege account that can submit or configure Webform content stores a malicious script payload in a field that is later rendered without proper neutralization. When a higher-privileged user - typically a site administrator reviewing submissions or form settings - views the affected page, the script executes in their authenticated browser session. No public exploit has been identified at time of analysis; the attack requires both authentication and victim interaction (UI:R).