Drupal Webform Security Update: Patch 22 Flaws Now

Drupal released Webform 6.2.12 and 6.3.1 on 23 September 2026 with a coordinated set of 22 security fixes and one additional hardening change. One advisory, CVE-2026-96355, is rated critical and can lead to information disclosure, stored cross-site scripting or remote code execution when a vulnerable form uses particular custom formatting.

This deserves immediate attention because Webform is not a niche add-on. Drupal.org reports more than 331,000 sites using the module. Organisations use it for contact forms, enquiries, applications, registrations, uploads, surveys and operational workflows—often with personal information moving into email, CRM, helpdesk, payment or reporting systems.

The correct response is broader than clicking update. Confirm every installation and branch, preserve evidence, create a restorable backup, deploy through a controlled environment, test the business journey around each form, and assess whether an exposed site shows signs of compromise. The Drupal Security Team also said this coordinated release was not covered by Drupal Steward, so site owners should not assume an external service has already mitigated it.

First, identify every affected site and version

Do not start with the most visible production website and assume the job is complete. Search the full estate: public websites, campaign sites, intranets, portals, development environments, disaster-recovery copies and older domains that still resolve. Include sites run by agencies or hosting partners.

For each site, record the Drupal version, Webform branch, installed version, hosting owner, code repository, deployment method and whether the site accepts public submissions. Supported targets are:

• Webform 6.2.x: update to 6.2.12. The release page lists compatibility with Drupal 10.2.
• Webform 6.3.x: update to 6.3.1. The release page lists compatibility with Drupal 10.3 and Drupal 11.

Drupal.org says no other Webform versions are supported. If a site is on an older branch, treat that as a separate upgrade and risk decision rather than assuming the 23 September patch can be applied directly.

Map exposure by feature, not only version

Every supported site below the fixed version should be updated, even if a quick configuration review suggests the critical path is absent. Exposure differs across the 22 issues. Inventory file uploads, public and private forms, Webform Share, JSON:API, Entity Print, Remote Post handlers, exports, imports, custom attributes, tokens, multiple-value item formats and any custom modules that render or transform submission data.

A seven-step Webform patch plan

1. Open an incident or change record. Name the business owner, technical owner, affected sites, decision log and communication route.
2. Preserve evidence before changing production. Retain relevant web, PHP, Drupal, WAF, authentication, file, database and integration logs according to your response plan. Record the current package and configuration state.
3. Create and verify a restorable backup. Back up code, Composer files, database, private files, public uploads and environment-specific configuration. Confirm who can restore it and where restoration will occur.
4. Update through Composer in a controlled environment. For a minor module update, Drupal's guide uses composer update drupal/webform --with-all-dependencies, followed by database updates and a cache rebuild. Review the resulting dependency and lock-file changes.
5. Run technical and business tests. Test each high-value form, access path, upload, email, integration and export with representative roles and data.
6. Deploy using the normal release path. Avoid editing package files directly on the server. Apply database updates, rebuild caches and verify configuration consistently across every instance.
7. Monitor and reconcile. Check errors, submission volumes, emails, queues, CRM records, uploads and user reports. Compare the business outcome—not just the HTTP status—with a known-good baseline.

If dependency constraints prevent the fixed version from resolving, do not force an unreviewed production change. Identify the blocker, involve the maintainer or development partner, restrict affected capabilities where practical, and plan an expedited compatible deployment.

Review for compromise instead of assuming patching closes the incident

The advisory describes possible information disclosure, stored cross-site scripting and remote code execution for the critical condition. If the affected configuration existed on an internet-facing site, review evidence proportionately. Useful questions include:

• Were unusual submissions or payload patterns received before the patch?
• Did PHP, the web server or the operating system launch unexpected processes?
• Did executable, template or unfamiliar files appear in writable directories?
• Were administrator accounts, permissions, handlers, email destinations or integration endpoints changed?
• Did exports, JSON:API responses, temporary files or private uploads show unusual access?
• Did downstream systems receive unexpected records, requests or authentication failures?

Absence of one log signal is not proof of safety. Retention may be short, proxies may hide client details, and successful misuse may leave evidence across several systems. Escalate to specialist incident response when the exposure, data sensitivity or available evidence exceeds the team's capability.

If immediate patching is blocked

A temporary control should reduce exposure while the fixed release is prepared; it should not become a substitute for updating. Depending on the affected features and business need, teams may consider pausing a non-essential form, restricting access, removing risky custom formatting, disabling an exposed integration, tightening WAF monitoring, or directing users to a safe alternative channel.

Choose controls from the actual configuration and the official advisories. Avoid broad changes that destroy evidence or create a second outage. Document the owner, start time, customer impact, monitoring signal and expiry condition for every temporary measure.

Australian Signals Directorate guidance recommends patching in a timeframe appropriate to exposure and maintaining clear patch processes, defined responsibilities and vulnerability scanning. For an internet-facing module with a public critical advisory, the business case for delay should be explicit, short-lived and reviewed by an accountable owner.

A practical checklist for business owners

• Ask your website provider for the installed Webform version on every Drupal site.
• Confirm 6.2.x sites are moving to 6.2.12 and 6.3.x sites to 6.3.1.
• Request evidence of a current, restorable backup before production deployment.
• Identify forms that accept uploads or sensitive personal information.
• List systems that receive form data, including email, CRM, helpdesk and storage.
• Approve a short test plan covering anonymous, authenticated and administrative roles.
• Ask whether the risky custom-formatting condition existed and what compromise checks were performed.
• Confirm monitoring after release covers both technical errors and missing business records.
• Record who owns future Drupal and contributed-module security advisories.

A useful completion statement is specific: every known site is inventoried, every supported installation is on a fixed release, critical journeys have passed, evidence review is documented, and any privacy assessment has an accountable owner.