tracker issue : CF-4204857

select a category, or use search below
(searches all categories and all time range)

latest update (June 2019) blocks upload of files with no extension, without offering a way to control that

| View in Tracker

Status/Resolution/Reason: To Fix//BugVerified

Reporter/Name(from Bugbase): Charlie A. / ()

Created: 07/14/2019

Components: General Server

Versions: 2016,2018

Failure Type: Incorrectly functioning

Found In Build/Fixed In Build: 2018,0,04,314546 /

Priority/Frequency: Normal / Few users will encounter

Locale/System: / Windows 10 64 bit

Vote Count: 4

Problem Summary:

The June 2019 updates of CF 2018, 2016, and 11 is now blocking upload of files with no extension. The problem is that a) this is not documented (in the tech notes or release notes for each update), and more important b) there is no way to ALLOW for such null file extensions, if desired.


As some readers will know, the April 2019 updates to CF2018, 2016, and 11 added a new security protection mechanism whereby CF would now block upload (processing, via cffile action=upload) of files with a set list of known server-executable file extensions (like cfm, jsp, aspx, php, etc.) 

This was enabled to prevent situations where unsuspecting developers (who didn't list what extensions SHOULD be allowed) were allowing server-executable files to be uploaded, and if placed into web-accessible folders, they were then executable by outsiders and allowed to run with the full permissions of the running CF instance.

The protection (to block the known risky file extensions) was enabled at the Admin, application, and tag level (cffile action="upload")--each overriding the one before it--whereby one could modify the list to allow some extension (such as if one knew they wanted to allow it but would upload the file to a non-web-accessible folder). 

Then this June 2019 update (update 4 of CF2018, with corresponding updates for 2016 and 11) has changed things so that files with NO extensions are automatically blocked.

The current workaround:

The problem with with the June 2019 update is that there is no means to ALLOW such files with no extensions. If someone uploads a file with no extension, it is blocked. 

The only way to allow it is to change the list of extensions (at either of the 3 levels) to be AN EMPTY STRING, which means do not block ANY file file uploads, regardless of extensions. (If it's made to be an * instead, that means block ALL file uploads, regardless of file extensions.)

The suggestions solution:

The new ability to block files with no extensions should have offered some means to indicate (in that list of "blocked extensions") when one DID or DID NOT want to block upload of files with no extensions. 

It could be an empty string (as one of the values in the list of extensions) or a NULL keyword. Then if it was there (by default, in the admin, like the other extensions blocked by default), it could be removed. As it stands (per the June update), there is NO indication that empty file extensions are blocked,  so there is nothing right now we can "remove", so as to PERMIT uploads of files with empty extensions, again other than removing ALL the listed blocked extensions, which then allows ANY. That's not desirable.

So first, the current technotes and release notes for the June update should be updated to reflect this change in behavior--and how the only way to allow uploads without extensions is to allow ALL extensions.

Then second, a new update should ALLOW for indication (or not) in the list of blocked extensions for whether files with no extensions should be blocked.


Yes ,someone may well decry that this is one of the problems with having a blacklist (what to block) rather than a whitelist (what to allow). Again, see the opening discussion here.  CF has indeed long had a whitelist feature. The problem was that if folks did not use it, then files with ANY extensions could be uploaded. This new feature (per the March update) was introduced to add protection where developers where not protecting themselves. This empty file extension is just a particularly challenging kind of thing to indicate in a blacklist, but it CAN be done.



I should have added that this arose in a forum discussion thread started by user noble6, who reported finding the problem as of the June 2019 updates. I replied suspecting that it sounded like it could be related to this new file upload mechanism protection added in the April update, though I knew of no provision there for empty file extensions. Brad Wood then confirmed the connection to this upload protection mechanism via a stack trace he had for a failing upload. That thread is here:
Comment by Charlie A.
31017 | July 14, 2019 01:51:55 PM GMT
This has caused a breaking change for a large govt client app I maintain in which users import a specific text file which is generated from payroll applications with no extension. This breaking change has affected their users ability to report their data and they need it to allow files with no extension again without lifting the current, and desired, black lists.
Vote by Bradley W.
31019 | July 15, 2019 03:51:39 AM GMT
Hi Charlie/Brad,   We are looking into it and will keep you posted   Thanks, Kailash
Comment by Kailash B.
31018 | July 15, 2019 05:21:57 AM GMT
I agree this should be fixed, but please make sure that using "*" will still block all file uploads, even those without extensions, eg: this.blockedExtForFileUpload="*"
Comment by Peter F.
31027 | July 15, 2019 07:22:23 PM GMT
I would suggest that being able to upload without file extension should be a separate setting. I wouldn't want to disable all upload protection just to allow for this one situation.
Comment by Chad N.
31029 | July 16, 2019 02:26:18 PM GMT
Chad, just to be clear: if you read my proposal, my proposal would not "disable all protection to allow for this one". I DO propose that it be a separate "setting", though not as a new checkbox or something, but rather as a new indication like the others naming what extensions to block. I can see some finding such a value to be more challenging than just a checkbox. But then consider that this blocked extension list can also be overridden at the app and tag level, so handling null extensions differently than others would require not only a new admin checkbox, but a new this scope variable for the app level, and a new attribute at the tag level. One might even propose that an option be offered in the tag to simply override the blocked file extension protection, such as if they knew they were uploading files to a non-web accessible folder, so that the risk of doing so was not as grave. Of course some could argue that once the file was uploaded, even to another folder, perhaps some other process (not considered) could cause the file to end up in a web-accessible folder. Language (and UI) design is a constant weighing of pros and cons. :-) I don't care so particularly HOW they solve this new problem, just that they do address it (especially as it was an undocumented change) for those wanting to upload files with null extensions.
Comment by Charlie A.
31030 | July 16, 2019 02:55:37 PM GMT
One way to address it, aside from adding another setting would be to add a special keyword, eg: no-extension, or null-extension in the extension list, then it could be supported in the Application.cfc, tag level, and Administrator level. I think there is little chance you would have someone who both wants to disable files without an extension but allow files with an extension of no-extension.
Comment by Peter F.
31031 | July 16, 2019 04:32:57 PM GMT
Yep, Pete. That was indeed what I originally suggested above. See "The suggestions solution:" (I see I made a typo there, but sadly we can't edit these.)
Comment by Charlie A.
31032 | July 16, 2019 04:52:45 PM GMT
From what I have seen in further research that HTML5 chunked uploaders could be affected. ------WebKitFormBoundary1ZBugAFy7SbAxWsA Content-Disposition: form-data; name="file.ext"; filename="blob" Content-Type: application/octet-stream That in the headers the filename="blob" is locked by the browser and is not accessible for modification. Can anyone confirm if they have had a similar experience?
Comment by Chad N.
31074 | July 26, 2019 05:35:47 PM GMT
Chad, you could help us confirm by offering us some sample code (client- and server-side, even if presented in a single template) that would demonstrate the problem, perhaps also with a file to use to demonstrate, if something about it may be unique. You should be able to zip those up and offer it as an attachment here. See the "choose file" button in the top right of the UI here.
Comment by Charlie A.
31075 | July 26, 2019 05:44:25 PM GMT
Charlie, I have uploaded a zip of an example that will trigger the problem. The original source code I have is highly integrated into our system, so I have taken an example that Ben Nadel had and modified it to cause the error. I upgraded the plupload to the same version we are using and the file upload.cfm endpoint to have a cffile. There is a directory called "upload_test_files" that has two text files that will trigger a successful and a failed upload. The chunk size is set to 1mb so any file below that threshold will upload successfully. Anything above the 1mb chunk size will error out. Below is a copy of the headers showing the difference on chrome dev tools. SOURCE FILE: test_small.txt ------WebKitFormBoundaryDEI4HSleTJA0aUNM Content-Disposition: form-data; name="file"; filename="test_small.txt" Content-Type: text/plain SOURCE FILE: test_large.txt ------WebKitFormBoundaryQ2c87iOEufeDvVZe Content-Disposition: form-data; name="file"; filename="blob" Content-Type: application/octet-stream Looking at demos of other html5 based upload systems have shown the same blob value when chunking as well as the content-type changing.
Comment by Chad N.
31076 | July 26, 2019 07:13:17 PM GMT