And note that if you are running CF multiserver (multiple instances), then by DEFAULT all new instances have the built-in web server enabled (specifically for accessing the Admin, before you may connect the instance to the external web server.) So bottom line: if you have the built-in web server enabled for CF, then a request to any CFM page (including the CFIDE folder's pages) can and will be sought and executed if found, even if it's only in the built-in web server root.So test all your sites to see if they respond to for instance.So as discussed above, do be sure to protect those directories, as discussed variously in the lockdown guides. You may find you can get into the CF Admin on sites where you don't even HAVE a CFIDE folder as a real or virtual directory (such as would be shown in IIS, but this can happen on Apache as well)!How could a request for /CFIDE/administrator/work when your web server docroot doesn't have that folder (nor a virtual folder), you might reasonably ask?This is a real surprise to some: CF has always had a capability whereby if you have the built-in web server enabled (the JRun web server in CF 6-9, or the Tomcat web server in CF10), then when a request is made for a CF page via the external web server (IIS or Apache, for instance), CF looks for the file FIRST in the external web web server's docroot, and THEN in the built-in web server's docroot, such as \coldfusion9\wwwroot or C:\JRun4\servers\cfusion\cfusion-ear\cfusion-war\wwwroot.Now, you may think you don't have the built-in web server enabled, but you may.
And then that page let them do things like access/manipulate files, and access DB info, including passwords.
Update: when you run it, you will be asked for a code. Just look for "code" in the source to find the value, and use that to get in.
You can then see that operations you perform lead to these web server log entries.
I'll update the other references to these directories, below.
And while certainly any current known vulnerabilities in those folders are indeed now fixed, there could be others that might appear later, so better to protect them now.] I didn't want to share too much info, but again I've been asked enough so I'll share at least this: the adminapi exploit allowed the hacker to create a scheduled task, and then that task called a page on another server, and the scheduled task was configured to "save" the output of that to this file.