CVE-2026-96366

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's file upload component doesn't check that the file ID sent back with a submission belongs to the user who submitted it. A submitter can edit that ID to attach another user's file to their own submission, and can then get the file through their submission view or an email notification (the email vector requires the site to use an HTML-capable mail module such as Mime Mail).

Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do, enabling attackers to access unauthorized functionality, data, or resources. It often stems from inadequate validation of user permissions, allowing someone to bypass intended security boundaries and perform actions beyond their assigned role.

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 medium-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, the Webform file component (_webform_render_file() in components/file.inc) rendered a core managed_file element and accepted whatever file ID came back in the hidden submitted[<key>][fid] field, never checking that the submitting user had uploaded that file. Core's file_managed_file_value() skips its access check for public:// files and only rejects other users' temporary files, so any submitter, including an anonymous one, could replace the fid with that of another user's permanent public upload. _webform_submit_file() stored the fid as supplied and webform_file_usage_adjust() then attached the file to the attacker's submission, so the attacker could open it through their own submission view or, when the webform emails attachments, receive it through _webform_attachments_file() without ever knowing the file's URL.

A secondary weakness meant that deleting the attacker's submission, either through "delete own webform submissions" or when an administrator cleared results, ran _webform_delete_file(): it calls file_usage_delete($file, 'webform') with no submission ID, which removes every Webform usage record for the file, then file_delete(), which permanently deletes the victim's file if no other module uses it. Where file renaming is configured, file_move() could relocate the victim's file in the same way.

Steps To Reproduce

1. On the latest stable version of Drupal 7, install a susceptible version of the Webform module (such as 7.x-4.27).
2. Enable Webform; accept enabling Chaos tools and Views when asked.
3. At admin/people/permissions, grant authenticated user the Access own webform submissions and Delete own webform submissions (needed for Impact 2) permissions, then Save permissions.
4. As an administrator, go to node/add/webform, set Title to "Upload test", click Save.
5. On the components page (node/N/webform/components), type Upload in New component name, choose File in the type dropdown, click Add, then Save component (defaults: Public files, gif/jpg/png).
6. As the administrator, submit the form once, uploading an image (victim.png). This creates a permanent public file owned by the admin — note its file ID from file_managed (IDs are sequential and guessable).
7. Create a second user, attacker, with only the authenticated role, and log in as them.

Impact 1: Disclosure (attacker reads a file they don't own)

8. Open the webform (node/N). In the page's hidden field <input name="submitted[upload][fid]" value="0">, change the value to the admin's file ID (here 1), then click Submit. You get "Thank you, your submission has been received."
9. As attacker, open your submission (node/N/submission/S).
   1. With vulnerable code:
      the Upload field links to victim.png, the admin's file.
   2. With fixed code:
      the field is empty, and admin/reports/dblog logs "The file ID … was not uploaded by this user and has been discarded."

Impact 2: Destruction (attacker deletes a file they don't own)

10. As attacker, delete that submission:
    node/N/submission/S/delete → "Are you sure you want to delete this submission?" → Delete.
    1. With vulnerable code:
       the admin's victim.png is removed from file_managed, file_usage, and disk.
    2. With fixed code:
       the file is untouched.

Addressing the Issue

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

• If the risk is unacceptable, remove file components from webforms that untrusted or anonymous users can submit or disable those webforms until the fix can be deployed.
• Revoke the "Access own webform submissions" and "Delete own webform submissions" permissions from untrusted roles, and turn off "Include files as attachments" on webform emails, so that a swapped-in file can't be viewed, received or deleted through an attacker's submission.
• Set the "Upload destination" of file components to Private files (this needs a private file system path configured) and move existing uploads there. This protects webform uploads but not other public files on the site.
• Audit webform submissions for file IDs that belong to files uploaded by other users (for example, where file_managed.uid differs from the submission's uid), and restore any deleted or moved files from backup.
• Sign up for post-EOL security support—HeroDevs customers get immediate access to a patched version of this module.

Credits

• Sandro Kneubühl (blackpharao)
• Omid Nasiri Pouya (omidsec)