Allow Unfiltered Uploads for Site Admins

By default (and for good rea­son), Word­Press lim­its the types of files which you may upload. You can show this your­self by going to the “Add Post” page, choos­ing to upload a file, and then upload­ing a PHP file. Word­Press will warn you that due to secu­ri­ty rea­sons, uploads of that file type are disallowed.

If, how­ev­er, you desire to upload what­ev­er you please, you can accom­plish that with a sim­ple one-lin­er to be added to The­siscustom_functions.php file:

define('ALLOW_UNFILTERED_UPLOADS', true);

Once added, any “super admins” (if mul­ti­site is enabled) or users who have the delete_users capa­bil­i­ty (on a sin­gle-site instal­la­tion) will have the unre­strict­ed abil­i­ty to upload what­ev­er they want.

Using that code, you have the pow­er to upload files to your site which could the­o­ret­i­cal­ly allow mali­cious users to take full con­trol of your web­site — any script which the serv­er can process will be exe­cut­ed any time a user vis­its your uploaded file, so please upload with dis­cre­tion! Also, unless you trust your entire admin team, do not use this code on a mul­ti-author blog.

8 thoughts on “Allow Unfiltered Uploads for Site Admins”

  1. “any script which the serv­er can process will be exe­cut­ed any time a user vis­its your uploaded file”

    I strong­ly doubt that is the case, but it would­n’t suprise me; it is Word­Press after all. It’s very easy to pre­vent files from being exe­cut­ed on down­load, if they have not imple­ment­ed that… well, that just sucks.

  2. Word­Press does­n’t mod­i­fy files which it uploads, besides pos­si­bly mak­ing opti­mized sizes of any uploaded images (a thumb­nail, for exam­ple). If you upload a PHP file, it’s going to sit in your uploads fold­er as a PHP file. 

    If you link to that file, then by default, the serv­er is going to exe­cute it. Servers can be con­fig­ured to not process PHP on the uploads direc­to­ry eas­i­ly enough; if you want unfil­tered uploads, then that’s what each site own­er should do. It’s going to be dif­fer­ent depend­ing upon which serv­er (Apache, for exam­ple) is in use.

  3. “Servers can be con­fig­ured to not process PHP on the uploads direc­to­ry eas­i­ly enough”

    That’s true, but an even eas­i­er and more secure solu­tion would be to do it through PHP. I’m strong­ly against the idea of link­ing to direct files that are uploaded by the user, part­ly because we don’t know what they are upload­ing. I would much pre­fer if WP has some sort of file-loader that sim­ply gets the file by ID and out­puts the con­tent in a safe way, be it a PHP/text/whatever file.

    So, when you were to request a file you’d do it like this:
    http://website.com/file/{id}

    And that would be received by a PHP file which fetch­es the file infor­ma­tion (includ­ing the real path), reads the file con­tents, and out­puts it safe­ly using head­er parameters.

    The only pos­si­ble issue with that is that peo­ple that know where the file is on the serv­er can go to the full URL and have the file exe­cut­ed — but that can be pre­vent­ed by gen­er­at­ing unique, hard-to-guess file/folder names for the uploaded files. They should also be kept out­side of the site root to pre­vent that. Above, com­bined with some .htac­cess (sure, it’s apache spe­cif­ic but it does­n’t hurt to include) would be super secure, and sexy!

    My point is, there’s no excuse for not remov­ing the upload fil­ter since secu­ri­ty is not a prob­lem. I’m work­ing on a Word­Press site atm that let’s reg­is­tered users upload files. I’ve tried tons of solu­tions and i still haven’t been able to ful­ly remove the upload fil­ter. It’s just a mess all­to­geth­er. The least they could do is make it eas­i­er to disable.

  4. Word­Press is secure in its default. Remov­ing the fil­ter is an admin­is­tra­tor choice, and with it comes some respon­si­bil­i­ty. Nobody should be remov­ing the fil­ter if they are not pre­pared to deal with the consequence.

  5. Brute force:

    vim wp-admin/includes/file.php

    // if ( ( !$type || !$ext ) && !current_user_can( ‘unfiltered_upload’ ) )
    // return call_user_func($upload_error_handler, $file, __( ‘Sor­ry, this file type is not per­mit­ted for secu­ri­ty reasons.’ ));

    It might not qual­i­fy as “good”, but it fixed our local prob­lem just now.

    1. This should prob­a­bly be done in wp-config.php, using define(‘ALLOW_UNFILTERED_UPLOADS’, true); — this will only work for admins as I under­stand it.

      It’s prob­a­bly unsafe to mod­i­fy Word­Press code direct­ly like this unless you have a sys­tem in place for track­ing your changes. For exam­ple a mod­i­fi­ca­tion like this won’t sur­vive an upgrade of Word­Press itself. Also this kind of change isn’t portable to oth­er installations…

      1. The way the The­sis theme works, mod­i­fy­ing its “cus­tom” files (which are out­side the theme direc­to­ry) is a safe way to add code cus­tomiza­tions which sur­vive updates.

        How­ev­er, you are right. This belongs in the Word­Press con­fig file. My mis­take there!

Leave a Comment

Your email address will not be published. Required fields are marked *

Use your Gravatar-enabled email address while commenting to automatically enhance your comment with some of Gravatar's open profile data.

Comments must be made in accordance with the comment policy. This site uses Akismet to reduce spam; learn how your comment data is processed.

You may use Markdown to format your comments; additionally, these HTML tags and attributes may be used: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Rick Beckman