Link Search Menu Expand Document

Unrestricted File Upload

  1. Unrestricted File Upload
    1. Description
    2. Impact
    3. Scenarios
    4. Prevention
    5. Testing


Unrestricted File Upload vulnerability occurs due to insufficient or improper file-type validation controls being implemented prior to files being uploaded to the web application. Without these methods of validation in place, a malicious actor may be able to craft the upload request to bypass the application-layer defenses and potentially completely compromise the system.

The OWASP Top 10 refers to Unrestricted File Uploads as a significant risk, and for good reason. Unrestricted File Uploads are an excellent primary entry point for an attacker, offering a foothold into the system for further escalation.


The impact of an Unrestricted File Upload vulnerability is usually high given that it facilitates code execution on target systems and web applications. Malicious actors might be able to escalate this to complete access by uploading and executing a web shell that can run commands, attack other servers, and be used as a staging point to pivot to other clients in the network.

In 2017, a security researcher participating in a bug bounty run by PayPal was able to leverage an Unrestricted File Upload vulnerability to execute remote code on the application. Companies of this size regularly run bug bounties to continually test their defenses for weaknesses, financially enticing security researchers to identify and report bugs before malicious actors exploit the same bugs. However, this is still an after-the-fact solution to a systemic problem that arises far earlier in the development cycle at the implementation stage.

Elaborating on the impacts, Unrestricted File Uploads can lead to Command Injection, XSS attacks, Denial of Service attacks, the creation of phishing pages, and other kinds of risks depending on the application technology and the uploaded file type.


Unrestricted File Upload vulnerabilities can be exploited in a variety of ways depending on the language used and the specific flaw exposed. Countermeasures and validation mechanisms do exist; however, sometimes they aren’t implemented at all, or if they are, the implementation is inadequate. The following are examples of preventative measures that can be bypassed:

  • MIME-type validation
  • Checking the file extension against a deny list
  • Image header checks

The following elaborates on Unrestricted File Upload manipulation as a result of non-existent validations in a PHP script.

A user is authorized by the following code to upload a picture of a flag (a SecureFlag picture even!) to the web server. The HTML code that facilitates the user end form has a file type input field.

<form action="upload_flagpics.php" method="post" enctype="multipart/form-data">

  Choose a file to upload:
  <input type="file" name="filename"/>
  <input type="submit" name="submit" value="Submit"/>


Upon submission, the form then sends the file to upload_flagpics.php on the web server. The file is stored in a temporary location by PHP until it is either retrieved or discarded on the server side. The file is then sent to a more permanent directory called flagpics/.

// Define the target location where the secureflag picture being
// uploaded is going to be saved.

$target = "flagpics/" . basename($_FILES['uploadedfile']['name']);

// Move the uploaded file to the new location.
if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target))
	echo "The picture has been successfully uploaded.";
	echo "There was an error uploading the picture, please try again.";

Unfortunately, the above code does not validate the file type being uploaded, and if the flagpics/ directory is accessible in the web document root, a malicious actor would be able to upload a file with the name malicious.php. This filename, ending in .php, can then be executed by the web server. Thus, a malicious actor could additionally send:


If this file is successfully installed by the attacker, they will be able to run arbitrary commands using a URL to execute, such as:

Thus, running the ls -al command.


Developers must review upload functionality to determine if uploaded content is ever returned to other application users and whether that is due to normal application usage or attack manipulation. As a part of this revision, developers should consider:

  • If the application filters file extensions and the MIME type of the uploaded file.
  • If placing executable JavaScript or HTML into the file is possible.
  • If the header information is returned after the contents of a file are downloaded.
  • If the storage location for uploaded content is escapable with a crafted filename.

There are numerous steps toward a more robust upload code architecture that developers must consider in their design:

  • Developers must use an allow list, enforcing acceptance of only listed, non-executable file extensions.
  • Developers should ensure file names do not contain directory traversal characters such as ../ that are used to place files outside of designated directory locations.
  • Developers should alter permissions on the upload folder to ensure the files can’t be executed.
  • Uploads must not be placed in directories that are accessible from the web.
  • Developers should ensure that if uploaded files are downloaded by users, they contain X-Content-Type-options: nosniff header and a Content-Disposition header that commands browsers to handle files as an attachment.
  • Uploaded files should be subject to immediate virus scanning.
  • Developers must enforce size limits on uploaded files and reject archive formats (like ZIP) from being uploaded at all.


Verify that user-uploaded files are stored in designated directories outside of the web root. If they must be displayed or downloaded from the applicationm, ensure they are served by either octet-stream downloads or from an unrelated domain.

Table of contents