· via dev.to (home feed)
Drupal Webform XSS (CVE-2026-96367) fixed in 6.2.12 and 6.3.1, sites urged to patch
Drupal has disclosed a moderately critical XSS flaw in the contributed Webform module, exploitable by authenticated users with form-editing rights. Sites should update to 6.2.12 or 6.3.1.

The Drupal Security Team has published an advisory for a cross-site scripting flaw in Webform, one of the most widely used contributed modules in the Drupal ecosystem. The issue, tracked as CVE-2026-96367 and described in advisory SA-CONTRIB-2026-162 on 23 September 2026, carries a risk rating of moderately critical (13/25). According to a write-up on dev.to summarizing the advisory, the fix is a version bump: 6.2.12 for sites on the 6.2.x branch and 6.3.1 for those on 6.3.x.
A permission gap, not an input-filter bug
Webform gives site builders an interface for creating forms, collecting submissions and controlling access to both. The root of the problem, per the advisory as reported by dev.to, is that the module fails to properly limit access to its custom attributes YAML editor. That creates a gap between two permission tiers: a user who may create or edit webforms — but deliberately has not been granted the stronger permission to edit raw webform source — can still add custom attributes through that editor. Those attributes then become the delivery vehicle for injected script.
Why the exploit needs a login
This is not an anonymous attack. The advisory's exploitation vector (AC:Basic/A:User/CI:Some/II:Some/E:Proof/TD:Uncommon) shows the attacker must be an authenticated user, and the E:Proof component indicates a proof of concept exists. Once planted, the script executes in the browser of anyone who later views the affected form. As with any cross-site scripting bug, the damage scales with the victim: a form seen mostly by anonymous visitors is a weaker target than one routinely opened by content editors or administrators.
Affected versions
dev.to lists the affected ranges as:
- Webform 6.2.x: all releases below 6.2.12
- Webform 6.3.x: 6.3.0 up to, but not including, 6.3.1
Installs already running 6.2.12 or 6.3.1 are not affected.
What site builders should do now
Upgrade first: move 6.2.x installs to 6.2.12 and 6.3.x installs to 6.3.1. Where an immediate update is not possible — during a change freeze, for instance — the advisory-backed fallback is to tighten which roles are allowed to create or edit webforms, and to audit who currently holds those permissions. Delegated roles deserve a close look, since permissions handed out during an initial site build can easily outlive the original need. CERT-BUND has also published the issue as WID-SEC-2026-3554, a sign it is being tracked beyond the Drupal project itself.
Why it matters
XSS that sits behind a login is routinely under-prioritized, and this advisory illustrates why that instinct is risky. The vulnerable capability — building forms — is exactly the sort of permission handed to junior staff, clients or contractors, so the pool of potential attackers on a real site is larger than it first appears. Compromise any one of those accounts and an outside actor inherits the same path. The exposure base is also hard to dismiss: a ZoomEye search cited by dev.to returned 436,325 fingerprinted Drupal assets. That figure counts Drupal, not Webform installations specifically, but it underlines how large the ecosystem is. With patched releases available for both supported branches, the practical takeaway is straightforward: update now, then confirm that webform-editing roles are as narrow as they should be.
- #drupal
- #security
- #xss
- #vulnerability
- #cms