CVE-2026-96357

Overview

Drupal is an open-source content management system known for its flexibility, robust features, and strong community support. Organizations of all sizes use it to build and manage dynamic websites and web applications.

Webform is a Drupal module for building forms and surveys, such as contact forms, questionnaires and registrations, that stores submissions in the database and can email notifications when a form is submitted.

Webform served uploaded files without forcing a download, so files of types the browser renders inline, such as HTML, XML or SVG, opened directly in the site's origin. Where a webform accepts those file types, a submitter can upload a file containing script that runs in the browser of anyone who opens it, typically a staff member reviewing the submission.

A cross-site scripting (XSS) vulnerability allows attackers to inject malicious scripts into webpages. It often occurs when a site fails to properly validate or sanitize user input, enabling the execution of unauthorized code within a victim's browser. It is included in the OWASP Top Ten list of vulnerabilities, specifically in the third category of Injection. A web site compromised in this way may experience:

• Session hijacking
• Data theft
• Malware distribution
• Defacement or phishing / privilege escalation.

Details

Module Info

• Product: Drupal 7
• Affected packages: Webform
• Affected versions: >=7.4.0 and <=7.4.27
• Repository: https://git.drupalcode.org/project/webform
• Published packages: https://www.drupal.org/project/webform
• Package manager: composer
• Fixed in: Webform NES 7.4.28

Vulnerability Info

This low-severity vulnerability is found in versions of the Drupal Webform module for Drupal 7 sites between versions 7.4.0 and 7.4.27 (inclusive).

Prior to the fix, an uploaded file's link carried no instruction to the browser about how to handle it, so a file of a type the browser renders inline ran in the site's origin instead of downloading. The File component's built-in checkboxes let a form builder allow HTML and XML uploads, and "Additional extensions" lets them allow any other type, including SVG. When such a file was displayed, theme_webform_display_file() (components/file.inc) and _webform_table_file() emitted a plain link to it, and for private files webform_file_download() (webform.module) returned only file_get_content_headers() — no Content-Disposition header — so opening the link rendered the file inline. A submitter could therefore upload a file containing script, and a victim who viewed the submission and opened the attachment would execute it in the site's origin (stored XSS).

The fix adds the HTML5 download attribute to those links and returns Content-Disposition: attachment from webform_file_download(), both via webform_file_force_download(), which matches the types in webform_file_download_mime_types() plus any +xml MIME type, so the browser saves the file instead of rendering it.

The header applies only to private files, which Drupal serves through webform_file_download(); public files are served directly by the web server, so opening a public upload's URL directly still renders it inline, and only the download attribute on Webform's own links protects them.

Addressing the Issue

Users of this module should apply one of the following mitigations:

• If the risk is unacceptable, remove the File component from webforms that untrusted or anonymous users can submit, or disable those webforms until the fix can be deployed.
• On any File component you keep, restrict the allowed extensions to types the browser won't render inline — uncheck "html" and "xml", and remove svg, htm, xhtml, and any similar entries from "Additional extensions" — so a submitter can't upload a file that executes script when opened.
• Force uploaded files to download at the web-server level: add Content-Disposition: attachment and X-Content-Type-Options: nosniff headers for the webform upload directory (for example, the webform/ folder under your public files) so browsers save these files instead of rendering them. This is the server-side equivalent of the fix.
• Set the "Upload destination" of File components to Private files (this needs a private file system path configured), which limits who can fetch an upload to users with access to the submission. Note this narrows exposure but does not stop inline rendering for a reviewer who opens the file, so pair it with the extension restriction above.
• Audit existing submissions for uploaded files of inline-rendering types (.html, .htm, .xml, .svg, .xhtml) and review or remove any that contain scripts.
• Sign up for post-EOL security support—HeroDevs customers get immediate access to a patched version of this module.

Credits

• Michael Maturi (michaelmaturi)