Hey folks, Pierre (@plarts) pointed me to this forum in talking with me about another problem of his. I shared this observation with him and want to share it here for readers of this thread.
As for the temp files referred to here, I’m a bit surprised that no one has yet pointed out that those come from HTTP uploads to a CF page (and have nothing to do with the CFIDE directory or Admin lockdown).
Any file upload to a CF page will be posted to that temp directory within CF. Of course, most CFM pages receiving an upload would then move it to a destination directory, using the CFFILE Action=”upload” and its DESTINATION attribute.
But while most people think it’s the CFFILE that “does the upload”, that’s just not the case. For more, see a blog entry I did on this very topic several years ago, which still holds true:
CFMythbusters: For a file to be uploaded to a CFM page, it needs a CFFILE Upload tag, right? Wrong!
http://www.carehart.org/blog/client/index.cfm/2006/5/7/cfform_not_doin g_upload
And I point out there also how such files should be removed at the end of each request. My understanding is that the only way they would remain would be if the request failed.
As for them being identified here as containing viruses, I suppose it's possible that a scanner may identify them as such by their pure file content, but as Anit seems to be pointing out, since these are just .tmp files, it would seem that nothing could really "execute" them (even if something somehow had execute privileges on the directory).
But if it concerns one that they are there, then just delete them. But you can't really stop them getting put there, since again any post of a file upload to any CFM will cause them to appear there. Again, though, they should disappear at the end of the request.
Separate from the concern about viruses (if there really should be one), I'll note that I also mention in the blog entry that this fact that any CFM page can "receive" an upload could technically be "abused" by someone, pushing files to the server.
But it's not also "entirely open", as there are some mechanisms in place (in the CF Admin) to throttle such file uploads somewhat. See the blog entry for more.
Finally, we should note that CF10 has added still more to help with this issue, in that if a CFFILE ACTION="upload" has a new STRICT attribute that causes CF to not only check the mime type (if listed in the ACCEPT attribute) but also makes sure that the file content itself matches that file content. There is also a new filegetmimetype that can be used against a file or directory of files to confirm if their contents meet their mime type.