Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.We have a simple form that has a file upload feature to attach PDF documents. It gets spammed by bots by uploading random PDFs without submitting the form. The files stay uploaded in the server and can be accessible at /sites/default/files/webform
Reproduce:
1. Create a webform.
2. Add a File field.
3. As anonymous select any file from your machine (based on what extensions are allowed to upload) and click upload.
4. Never submit the form, the file stays uploaded.
5. File is accessible to public.
6. Using module https://www.drupal.org/project/file_entity uploaded spam files can be tracked at admin/content/file
Anti-spam modules like Google reCAPTCHA are bypassed, because you need to fill it only to submit the form, spammer does not need to submit the form to fill the server with advertised PDF files.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | firefox_2021-11-03_19-28-47.png | 17.36 KB | matas.k |
| #6 | demo.gif | 108.57 KB | matas.k |
| firefox_2021-11-03_16-54-44.png | 91.19 KB | matas.k |
Comments
Comment #2
cilefen commentedIs there a reason this site stores Webform uploads in the public file system?
#2816303: File upload destination should be private files by default if available
Comment #3
matas.k commentedHi, I changed it to private, so now it is uploaded outside web directory e.g. system/files/webform/
But this doesn't solve anything, because the spam bots can still upload (to private directory) files without submitting the form? The files stay in the server, taking up the space and filling up website with junk file listings (like at e.g. admin/content/file a view generated with file_entity module).
Comment #4
cilefen commentedI think cron should clean those up because they are marked temporary.
https://www.drupal.org/psa-2016-003
Comment #5
matas.k commentedMarked temporary how? Where to check this?
I ran cron manually and with drush, it does not get deleted.
File is uploaded straight to private file system path without submitting the form, not to temporary directory.
This is on fresh vanilla installation.
Comment #6
matas.k commentedI attached a small demonstration.
Comment #7
matas.k commentedIt is not treated as temporary, because it is added to views list on upload without submitting the form.
Comment #8
matas.k commentedOkay, looks like it gets deleted maybe within 24 hours. Still, would be nice to edit that or avoid from being uploaded at first place. Keep it clean.
Comment #9
featuriz commentedIt's not just webform module problem. It's entire drupal problem. I'm using 9.x . In my custom form file, SAME ERROR LIKE #6. There is no proper documentation for this. To solve this I set empty array for ```'#library' => []```. But when I set this SAME form as block, file is not uploading. When debug, the file is not even uploading to the server. So I have to remove '#library '. If someone knows on solving this problem, please do post.
Comment #10
oriol_e9gIMO It's a low-risk security problem. In our case PDF files with malicious links are submitted constantly. These malicious files are uploaded to private folder and then deleted by cron, but malicious files are constantly being sent so there are always some malicious files on the server.
This is still a risk by our users because they can find this files using modules like IMCE or File browser. Uploading a PDF, PSD or GIF file in a user accessible folder can be used to exploit a zero-day vulnerability like FORCEDENTRY if users are using a mobile and simple check the file, or include malicous links inside PDFs files to try to pishing if someone found this files browsing.
Uploaded files should be uploaded to temporally folder and then moved to private or public folder when the form was submited and validated. This would be safer because forms implement anti-bot filters that are being skipped in file submit.
Comment #11
oriol_e9gComment #12
solideogloria commentedIssues should target the newest branch. If a fix is released, it could potentially be backported.
Comment #13
cilefen commentedThis report doesn’t seem to be different than this Core issue—the desire for temporary files to be sequestered on disk—so I am closing it.