Webform Security Release: 20 Advisories in One Day, and the Order to Patch In

The Drupal webform security release of September 23, 2026 fixed 20 advisories in one module on one afternoon, and one of them is rated Critical for remote code execution. The fixes are in Webform 6.2.12 and Webform 6.3.1. Drupal Steward, the security team’s network-level shield, does not cover this release.

Webform’s drupal.org project page reports 331,609 sites using it. For the nonprofits, associations, colleges and public agencies we write for, forms are where the site takes donations, registrations, applications and member data. This piece walks through what shipped, how the 20 advisories group by who can exploit them, which branch you need, and a patch order for agencies that run many client sites.

The short version: update every site to 6.2.12 or 6.3.1 this week, and do the sites with public forms first. Six of the 20 advisories can be reached by anonymous visitors under certain configurations, including the critical one. The other 14 Webform security flaws need a logged-in account, and most need form-building rights. That split decides the order, not whether to patch.

What shipped on September 23

The Drupal Security Team gave notice two days early. PSA-2026-09-21 said a "widely used contributed module" would get a security release on September 23 between 17:00 and 21:00 UTC. It said the highest risk score was critical. An update on September 21 added that "These releases will not be covered by Drupal Steward." A second update on September 22 warned that the issues might be reachable in more common configurations than first thought.

The module was Webform. The advisories run from SA-CONTRIB-2026-154 to SA-CONTRIB-2026-175. Numbers 156 and 157 are not on the contributed project advisory list, so the Webform set is 20 advisories, not 22.

That gap causes some confusion. The Webform 6.3.1 release notes describe "a coordinated set of 22 security fixes with advisories and one additional hardening change." The same page links 20 advisory IDs. Neither page explains the difference. Count 20 advisories and 22 fixes, and you will match both.

By type, the 20 Webform security advisories break down like this:

• Cross-site scripting: 10 advisories.
• Access bypass: 8 advisories, one of which also covers server-side request forgery.
• Denial of service: 1 advisory.
• Remote code execution: 1 advisory.

By risk level, one is Critical, 16 are Moderately critical and 3 are Less critical.

Webform was not alone that day. The DropTimes counted 36 contributed project advisories across 16 projects. Other critical ones included Project Browser (SA-CONTRIB-2026-178, cross-site request forgery, fixed in 2.0.3 and 2.1.5), the Cloud module and Tawk.to. If you run Project Browser, it belongs in the same maintenance window.

How to read a Drupal risk score

Every advisory carries a score out of 25 and a short vector string. Two parts of that string matter most for triage.

The first is A, for authentication. Drupal’s risk level definitions use three values. "None" means all or anonymous users. "User" means basic, commonly assigned permissions. "Admin" means broad permissions.

The second is E, for exploit. "Theoretical" means no public exploit code exists. "Proof" means documented methods for building one exist. "Exploit" means "documented or deployed exploit code already in the wild."

A third part, TD, says whether default configurations are exposed or only uncommon ones. Most Webform security advisories in this set are rated Uncommon. That lowers the score, but it does not help a site that uses the uncommon feature.

Scores run in bands: 5 to 9 is Less critical, 10 to 14 is Moderately critical, 15 to 19 is Critical, and 20 to 25 is Highly critical. Nothing in this release reached Highly critical.

Six Webform security flaws anonymous visitors can reach

These six advisories are scored with no authentication required. Each one still depends on a specific feature or configuration, listed in the last column.

Read the last column before you relax. File uploads are common on application and registration forms. Remote Post handlers are common on sites that push submissions to a CRM or an association management system. Those are exactly the integrations many nonprofit and association sites run.

Fourteen Webform security flaws that need an account

The other 14 advisories need a logged-in user. Most need permission to create or edit webforms, which on many client sites is held by more people than it should be.

This is the group where internal risk lives. A volunteer, a temporary staff member or a departed contractor who still has a builder role can use several of these.

The critical one: SA-CONTRIB-2026-175

SA-CONTRIB-2026-175 scores 18 out of 25. Its vector is AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:Uncommon. In plain terms: easy to trigger, no login needed, full confidentiality and integrity impact, no public exploit, uncommon configuration.

The advisory says Webform "does not sufficiently exclude certain format templates from token replacement." An attacker can submit data that gets evaluated as template code when the submission is rendered. Depending on the site, that "may lead to information disclosure, stored cross-site scripting, or remote code execution."

The limiting condition is specific. The advisory says an affected webform "must be configured with a custom multiple-value item format that includes submission-value tokens." Most simple contact forms will not have that. Complex forms built by agencies sometimes do, because custom formats are how you make multi-value answers readable in emails and confirmation pages.

The CVE is CVE-2026-96355. As of September 27, 2026, the advisory does not report exploitation in the wild.

The one with a public exploit: SA-CONTRIB-2026-171

Only one advisory in the set is rated E:Exploit. One other, SA-CONTRIB-2026-162, is rated E:Proof. The remaining 18 are Theoretical. SA-CONTRIB-2026-171 scores 14 with the vector AC:Basic/A:None/CI:None/II:Some/E:Exploit/TD:Uncommon.

Under Drupal’s definitions, E:Exploit means exploit code or a documented exploit exists. It does not mean the security team has confirmed attacks against live sites. The advisory makes no such claim.

The flaw is narrow. According to the advisory, "submissions for an Ajax-enabled Webform using Webform Share can bypass anti-spam protections." All three conditions must hold: Webform Share is enabled, sharing is turned on for that form, and the form depends on Form API anti-spam tools such as Honeypot or Antibot.

The impact is spam, not a breach. For an organization that embeds shared forms on partner sites, spam can still mean junk in a CRM and bad data in a member database.

Which branch carries the Webform security fixes

The fix depends on your branch, and your branch depends on your Drupal core version.

The 6.2.12 release carries the same fixes as 6.3.1. It is the right move for a Drupal 10 site that is not ready to change branches today. Jumping from 6.2.x to 6.3.x is a separate change and deserves its own testing.

The 6.2.x line ends with Drupal 10. We covered that date, December 9, 2026, in what Drupal 10 end of life means. Sites still on Drupal 10 and Webform 6.2.x have two upgrades ahead of them, and this release is a good reason to plan both. Our Drupal 10 to 11 upgrade guide covers the core side.

One small trap: the solution line of SA-CONTRIB-2026-167 says to upgrade to "Webform 6.3.11." Its own affected-versions line ends at 6.3.1, and the project page lists 6.3.1 as current. Treat 6.3.1 as the target.

Drupal Steward does not cover this release

Drupal Steward is a security filter that runs at the network level. It is meant to block exploitation of a flaw before sites have patched.

Its FAQ says its main strength is "protecting against mass-exploitable vulnerabilities," the kind most likely to be rated highly critical in core. For contributed modules, coverage depends "on the nature of the vulnerability and the discretion of the Security Working Group." The team must also decide whether a flaw can be mitigated at the network level at all.

For this release, the PSA answered the question directly: no coverage. If a client believes Steward buys them time, it does not this time. The only protection is the update.

A patch order for agencies running many sites

The update is the same for every site. The order is what changes. Here is a practical sequence for a portfolio of client sites.

1. Inventory first. List every site with Webform installed, its version, its branch and its Drupal core version. Note which sites use the file upload element, Webform Share, Remote Post handlers, Submission Export/Import, Entity Print or JSON:API.
2. Public forms with risky features. Patch sites whose public forms use file uploads, Remote Post handlers, Webform Share or custom multiple-value formats. These map to the six anonymous-reachable advisories.
3. All other sites with public forms. Donation, event and contact forms fall here.
4. Sites with many builder accounts. Large editorial teams and sites with shared logins carry more internal risk from the builder-level advisories.
5. Internal-only and low-traffic sites. Still patch them. They just go last.

This Webform security release is not a one-off. The same pattern showed up in fifteen contrib advisories on one day earlier this month. It is also consistent with what we wrote about the Drupal AI Security Initiative making bugs cheaper to find. Agencies should expect more batch days like this one.

The update, step by step

For a Composer-managed site, applying the Webform security fixes is routine.

1. Back up the database and confirm you can restore it.
2. Update the package. On 6.3.x, run composer require 'drupal/webform:^6.3.1'. On 6.2.x, run composer require 'drupal/webform:^6.2.12'.
3. Run database updates with drush updb, even if you expect none.
4. Rebuild caches with drush cr.
5. Confirm the version with composer show drupal/webform or on the Available updates report.
6. Test before production, then deploy through your normal workflow.

On Pantheon, the Composer steps happen locally or in your build tooling. Pantheon’s Integrated Composer documentation says to commit composer.json and composer.lock and push. On push, the platform runs composer install from the lock file. Database updates then run through Terminus with remote:drush, for example terminus remote:drush site.env -- updb. Test outside production before you deploy.

What to check after the Webform security update

A Webform security release this size touches a lot of code paths. Test the things that carry the most weight for the client.

• Submit every critical form. Donations, registrations, applications and membership forms, as an anonymous visitor and as a logged-in user.
• Check handlers. Confirm email handlers still send and Remote Post handlers still reach your CRM or AMS. SA-CONTRIB-2026-167 adds a new permission, “Administer webform remote post URLs.” The advisory says to grant it only to trusted roles.
• Check submissions. Open recent submissions, results pages and exports. Confirm the right roles see the right fields.
• Check remote imports. SA-CONTRIB-2026-164 tells sites that need remote imports to list trusted hosts in settings.php with webform_submission_export_import_csv_hosts and webform_submission_export_import_file_hosts.
• Watch for a new autocomplete warning. The release adds a hardening change that warns builders when an autocomplete element exposes values from existing submissions.

If a form handles uploads, submit a test file and download it. That exercises the file-delivery fixes, and it is the same class of risk we covered in the Gravity Forms file upload flaw on the WordPress side.

If you cannot apply the Webform security release today

The advisories offer no official workaround. Every solution line says to install 6.2.12 or 6.3.1. What they do offer is a list of conditions, and you can check those while you schedule the update.

• For the critical flaw: look for any webform with a custom multiple-value item format that includes submission-value tokens. That is the condition SA-CONTRIB-2026-175 names.
• For builder-level flaws: review who holds create, edit and administer permissions on webforms. Several advisories name those permissions as the limiting factor. Remove stale accounts.
• For optional submodules: note whether Webform Share, Submission Export/Import and Webform Entity Print are enabled. Several advisories only apply when they are.
• For JSON:API: check whether any webform exposes submissions through JSON:API.

Disabling a submodule is a site change with its own risks. Weigh it against how quickly you can ship the real fix.

Frequently Asked Questions