Drupal Webform CVE-2026-96355: when ordinary form input can become code

The Drupal Security Team published a critical advisory on 23 September for the widely used Webform module. CVE-2026-96355 can cause data submitted through a form to be evaluated later as template code. Depending on configuration, the outcome can range from information disclosure and stored cross-site scripting to remote code execution.

This is not a Drupal Core vulnerability, and it does not make every Webform vulnerable. It affects sites with a particular custom multiple-value item format that contains submission-value tokens. Because forms are commonly public, however, an attacker may not need an account.

Versions that require an update

SA-CONTRIB-2026-175 lists the following as affected:

• Webform 6.2 releases before 6.2.12;
• Webform 6.3.0 before 6.3.1.

The solution is to move to Webform 6.2.12 or 6.3.1 respectively. The Drupal Security Team rates the issue Critical, 18/25. The custom-format configuration is a precondition, and some consequences also depend on other enabled modules and site-specific settings.

Administrators should account for a practical trap: the version recorded in a deployment repository may not be the version serving production traffic. An old container, stale node or failed rollout may still be online.

Why a form is a security boundary

A contact form looks harmless, but it connects an anonymous user to a database, email, CRM, files and an employee’s administration screen. Data submitted today may be rendered later in a confirmation, export or back-office view.

When a system replaces tokens in a configurable template and mistakes user data for part of that template, content crosses from “data” into “instruction”. Businesses encounter the same underlying design risk in document generators, transactional messaging and low-code tools.

The risk does not end at the web server. A compromised application may reach customer databases, SMTP, object storage, webhooks and keys for marketing systems. Incident ownership therefore cannot sit only with the CMS administrator.

What to do today

First build an inventory of Drupal sites and identify where Webform is enabled. Include recruitment portals, internet-accessible intranets, event sites and old campaign pages as well as the main corporate site.

Then:

1. confirm the deployed module version on every environment;
2. preserve configuration, files, the database and logs needed for possible investigation;
3. update Webform to 6.2.12 or 6.3.1;
4. run the required database updates and rebuild caches under the Drupal deployment procedure;
5. test public forms, confirmation views, mail notifications, exports and integrations;
6. review custom multiple-value formats and submission-value tokens;
7. confirm the version on every node after rollout.

Disabling one affected form can reduce risk temporarily when an update needs a maintenance window. It does not replace the patch or protect other forms with comparable configuration.

How to look for exploitation

Start with submissions to forms using custom rendering. Look for content inconsistent with normal business data, unusual template syntax, long encoded strings and attempts to influence rendering. Correlate the submission time with a later back-office view, generated message or export.

On the server, review changed files, new processes, outbound connections, unusual rendering errors and administrator activity. In the database and configuration, inspect new roles, changed permissions, form handlers and unexpected integrations.

The absence of a WAF alert does not prove safety. Malicious input may look like ordinary text when submitted, and the dangerous effect may occur only when a staff member opens the submission or a particular view renders it.

Business decisions, not only Drupal work

Establish what each affected form collects. Recruitment may involve CVs, addresses and employment history; a sales enquiry may reveal contact details and infrastructure needs; a support form may contain attachments, identifiers and customer information. That map determines the investigation scope and any legal or notification obligations.

If you find signs of code execution, do not reflexively delete them before preserving evidence. Isolate the service, start the incident procedure, identify accessible secrets and rebuild the application from a trusted source. Rotate credentials in a controlled order after closing the entry path.

Source facts and Breachroad assessment

The Drupal Security Team confirms CVE-2026-96355, affected and fixed versions, the required custom format, a path available to anonymous input and consequences ranging from disclosure and XSS to RCE. The advisory does not confirm mass exploitation and explicitly makes exposure configuration-dependent.

The inventory, submission-to-render correlation, connection review and form-data assessment are Breachroad recommendations. Web application security training helps teams recognise boundaries between data and code, while a web application penetration test can validate the real form, permission and integration paths.