Drupal SafeDelete EUVD-2026-107859

Exploitation requires (1) a Drupal site running SafeDelete between 0.0.0 and 1.0.88, (2) an attacker holding a low-privileged authenticated account that can submit input into the affected SafeDelete field (PR:L - unauthenticated anonymous users cannot exploit this), and (3) a second user, typically an administrator or content reviewer, subsequently loading the page where the payload is rendered (UI:R). These two prerequisites - authenticated write access plus required victim interaction - are the principal limiting factors and meaningfully reduce real-world risk below what the network attack vector alone implies. The available sources do not name the exact field, form, or SafeDelete feature that fails to neutralize the input, so the precise injection point should be confirmed from the Drupal advisory.

This is a moderate-severity stored Cross-Site Scripting flaw (CWE-79) in the Drupal SafeDelete contributed module, rated CVSS 4.6. The CVSS vector (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N) indicates network reach but constrained real-world impact: PR:L means the attacker must already hold a low-privileged authenticated account on the site, UI:R means a victim must view the page where the payload is stored, and C:L/I:L/A:N limits impact to partial confidentiality/integrity with no availability effect. The exploitation signals reinforce low urgency rather than contradict it: EPSS is 0.16% (5th percentile), there is no CISA KEV listing, and no public exploit was identified at time of analysis. The vuln.today decision label is 'this_month,' consistent with a patch-when-convenient posture rather than emergency remediation. No signals conflict here - a low EPSS, absent KEV, and a mid-range CVSS all point the same way. The main caveat is that stored XSS against an administrative user can escalate beyond the C:L/I:L rating if the injected script hijacks an admin session, so the practical impact depends on which user roles can reach the injection point; the available sources do not specify that, so it should be verified against the Drupal advisory.

A low-privileged authenticated user on a Drupal site running a vulnerable SafeDelete version submits input containing a malicious script into a field that is not properly sanitized before being rendered. The payload is stored and later executes in the browser of another user - typically an administrator reviewing the content - allowing session token theft or actions in that victim's context. No public exploit code was identified at time of analysis, and successful exploitation requires the victim to load the affected page (UI:R).