Drupal’s September 23, 2026, contributed-project security release brought a critical advisory for Webform: SA-CONTRIB-2026-175. The Drupal Security Team had warned on September 21 that a widely used module would receive a significant number of advisories, and updated that warning on September 22 to say the issues might affect more common configurations than initially expected.[1] For Webform maintainers, the useful response is not to assume every form is exploitable. It is to update promptly and check the particular rendering configuration described in the advisory.[7]
What the Webform advisory says
Webform does not sufficiently exclude certain format templates from token replacement. An attacker may be able to submit data that is evaluated as template code when a submission is rendered. Depending on the site’s configuration and enabled modules, the consequences can include information disclosure, stored cross-site scripting, or remote code execution.[7]

The advisory identifies an important condition: an affected webform must use a custom multiple-value item format containing submission-value tokens. That is narrower than “any site with Webform installed,” but it is not a reason to postpone the update. A configuration audit can miss an old form, an infrequently used submission view, or a format introduced through imported configuration.[7]
Find the configurations that need attention
I would start with an inventory of the Webform versions deployed across production, staging, and any separately maintained sites. Then I would review custom formatting on forms that collect multiple values, paying particular attention to formats that insert submission-value tokens into rendered output. Check both the active site configuration and configuration stored in the repository: they may differ if changes have not yet been deployed.
Prioritize forms whose submissions are displayed to other users or reviewed in administrative workflows. The advisory describes evaluation when a submission is rendered, so testing only the form’s input page does not exercise the relevant path.[7] If you find a matching format, record where it is used before changing it; that makes it easier to verify the update and spot any unintended display changes.
Update with a controlled Composer deployment
Consult the advisory for the fixed release appropriate to your installed Webform branch, then make the dependency change in a development branch. On a Composer-managed site, the workflow might begin like this:
composer show drupal/webform
composer update drupal/webform --with-all-dependencies --dry-run
composer update drupal/webform --with-all-dependencies
Review the proposed dependency changes before committing the lockfile. If the update cannot resolve cleanly, investigate the constraint rather than forcing a version that the site has not tested. The advisory’s recommended solution is to install the latest version; your deployment still needs to follow the release and compatibility guidance for your site.[7]
Deploy through the normal pipeline, apply any required database updates, and rebuild caches. On staging, submit harmless test data to an affected form and inspect the resulting submission display. Confirm that intended formatting still works, access permissions remain correct, and submitted values appear as data rather than being interpreted as template instructions. Do not use production submissions as a test payload.
Treat the warning as a prompt to improve inventory
The advance notice was unusually useful: it gave Drupal teams time to identify owners and reserve a deployment window before the security release. It also explicitly said the release was not covered by Drupal Steward, so teams could not treat that service as their patch plan.[1]
The lasting lesson is practical. Keep a record of which forms use custom submission formatting and who owns them. The next advisory may concern a different feature, but a current configuration inventory makes it much faster to determine whether an urgent patch also needs a targeted review.
References
- Upcoming critical contributed project security release on September 23, 2026 – PSA-2026-09-21 — https://www.drupal.org/psa-2026-09-21
- Webform – Critical – Remote Code Execution – SA-CONTRIB-2026-175 — https://www.drupal.org/sa-contrib-2026-175


Leave a Reply