Allow Unfiltered Uploads for Site Admins

By default (and for good reason), WordPress limits the types of files which you may upload. You can show this yourself by going to the “Add Post” page, choosing to upload a file, and then uploading a PHP file. WordPress will warn you that due to security reasons, uploads of that file type are disallowed.

If, however, you desire to upload whatever you please, you can accomplish that with a simple one-liner to be added to Thesiscustom_functions.php file:

define('ALLOW_UNFILTERED_UPLOADS', true);

Once added, any “super admins” (if multisite is enabled) or users who have the delete_users capability (on a single-site installation) will have the unrestricted ability to upload whatever they want.

Using that code, you have the power to upload files to your site which could theoretically allow malicious users to take full control of your website — any script which the server can process will be executed any time a user visits your uploaded file, so please upload with discretion! Also, unless you trust your entire admin team, do not use this code on a multi-author blog.

8 thoughts on “Allow Unfiltered Uploads for Site Admins”

  1. “any script which the server can process will be executed any time a user visits your uploaded file”

    I strongly doubt that is the case, but it wouldn’t suprise me; it is WordPress after all. It’s very easy to prevent files from being executed on download, if they have not implemented that… well, that just sucks.

  2. WordPress doesn’t modify files which it uploads, besides possibly making optimized sizes of any uploaded images (a thumbnail, for example). If you upload a PHP file, it’s going to sit in your uploads folder as a PHP file.

    If you link to that file, then by default, the server is going to execute it. Servers can be configured to not process PHP on the uploads directory easily enough; if you want unfiltered uploads, then that’s what each site owner should do. It’s going to be different depending upon which server (Apache, for example) is in use.

  3. “Servers can be configured to not process PHP on the uploads directory easily enough”

    That’s true, but an even easier and more secure solution would be to do it through PHP. I’m strongly against the idea of linking to direct files that are uploaded by the user, partly because we don’t know what they are uploading. I would much prefer if WP has some sort of file-loader that simply gets the file by ID and outputs the content 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 fetches the file information (including the real path), reads the file contents, and outputs it safely using header parameters.

    The only possible issue with that is that people that know where the file is on the server can go to the full URL and have the file executed – but that can be prevented by generating unique, hard-to-guess file/folder names for the uploaded files. They should also be kept outside of the site root to prevent that. Above, combined with some .htaccess (sure, it’s apache specific but it doesn’t hurt to include) would be super secure, and sexy!

    My point is, there’s no excuse for not removing the upload filter since security is not a problem. I’m working on a WordPress site atm that let’s registered users upload files. I’ve tried tons of solutions and i still haven’t been able to fully remove the upload filter. It’s just a mess alltogether. The least they could do is make it easier to disable.

  4. WordPress is secure in its default. Removing the filter is an administrator choice, and with it comes some responsibility. Nobody should be removing the filter if they are not prepared 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, __( ‘Sorry, this file type is not permitted for security reasons.’ ));

    It might not qualify as “good”, but it fixed our local problem just now.

    1. This should probably be done in wp-config.php, using define(‘ALLOW_UNFILTERED_UPLOADS’, true); – this will only work for admins as I understand it.

      It’s probably unsafe to modify WordPress code directly like this unless you have a system in place for tracking your changes. For example a modification like this won’t survive an upgrade of WordPress itself. Also this kind of change isn’t portable to other installations…

      1. The way the Thesis theme works, modifying its “custom” files (which are outside the theme directory) is a safe way to add code customizations which survive updates.

        However, you are right. This belongs in the WordPress config file. My mistake 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>

This site uses Akismet to reduce spam. Learn how your comment data is processed.

the Rick Beckman archive
Scroll to Top