Introduction

File upload functionality One of the most prevalent features in contemporary web apps is file upload functionality, which is also one of the riskiest when not used properly. I found a high-impact vulnerability during a recent security audit that started with a seemingly innocuous feature: uploading profile images. identifying dubious redirection in order to reduce the dangers related to this vulnerability.A online application that allowed users to upload a profile avatar image had a high-impact vulnerability found during a recent security evaluation. Although this feature first seemed innocuous, inadequate file validation gave attackers the chance to upload malicious programs to the site. At first, it appeared that the upload process had some fundamental safeguards, like the usage of multipart form-data requests and the existence of a CSRF token. After the upload, the program also showed a preview of the image, creating the illusion that the file handling procedure was safe. Nevertheless, additional testing showed that the program did not correctly verify the type and content of the uploaded file.

In this blog post, I’ll explain how a seemingly straightforward avatar upload feature was used to upload a PHP web shell, which resulted in the server being fully compromised.

Hi Bounty Hunters,

I recently found File upload Vulnerability issue so let’s discuss about it and get started.

File upload functionality is a very common feature in modern web applications. Many platforms allow users to upload files such as profile images, documents, or attachments. However, when this feature is not implemented securely, it can become a critical attack vector.

In this case, the application allowed users to upload a profile avatar image through the endpoint:

Target Functionality

The application provides a feature that allows users to upload a profile avatar through their account settings. This functionality is intended to enable users to personalize their profiles by uploading an image.

The request uses multipart/form-data, which is a standard method for uploading files through web forms. During the upload process, the application accepts image files and stores them on the server for later display on the user’s profile.

The application allowed users to:

• Upload profile avatar via:
  POST /my-account/avatar
• Accepted image files
• Stored files under:
• The upload appeared secure at first:
• Multipart form-data used
• CSRF token present
• Image preview after upload

However, the key observation was: Uploaded files were stored inside a web-ccessible directory.

This immediately made the feature high risk.

Observed Security Controls

At first glance, the upload mechanism appeared to implement several security measures, suggesting that the functionality was designed with some level of protection.

Observed controls included:

• The usual file upload format, multipart/form-data, was utilized in the file upload request.
  The request contained a CSRF token, signifying defense against Cross-Site Request Forgery attacks.
  Following upload, the program produced an image preview to verify that the file had been successfully saved and linked to the user profile. Malicious files were eventually able to be uploaded and executed because the file upload process lacked enough server-side validation and security measures, despite these seeming safeguards.

Testing File Type Validation

To understand how the application validates uploaded files, I began testing the file upload functionality by intercepting the avatar upload request using a web proxy.

I intercepted the request using Burp Suite. Original Request

POST /my-account/avatar
Content-Type: multipart/form-data
filename=” avatar. jpg”

I modified it to upload a PHP file:

filename=”shell.php”
Content-Type: application/x-php

Result: Upload successful Server response confirmed:

Accessing the Uploaded File

After successfully uploading the malicious file to the server, the next step was to verify whether the file could be accessed and executed through the web application. The uploaded file was stored in a publicly accessible directory used by the application to store user avatars.

To determine the level of privileges under which the commands were being executed, the following command was issued

Next, I navigated to:

/files/avatars/shell.php

Then executed a command:

/files/avatars/shell.php?cmd=ls

Response showed system output.

To confirm execution level: /files/avatars/shell.php?cmd=id

Result: uid=0(root) gid=0(root)

This confirmed Remote Code Execution.

Root Cause Analysis

The vulnerability existed due to multiple design failures:

Issue Impact No extension validation PHP file uploaded Files stored in web root Executed by server No content inspection Arbitrary code allowedNo filename sanitization Path traversal possible No execution restrictions Full command execution

Exploitation Impact

This vulnerability allows:

Remote Code Execution

Attacker can execute any system command:

whoami
cat /etc/passwd
ls -la
2. Server Takeover

Possible actions: Upload reverse shell Modify application files Access database credentials Pivot inside internal network

Server Takeover

Once remote code execution is achieved, attackers can perform various malicious actions, including:

• Uploading a reverse shell to maintain remote access
• Modifying or replacing application source code
• Extracting database credentials from configuration files
• Accessing sensitive user data stored in databases
• Pivoting into the internal network to compromise additional systems
• Installing backdoors for persistent access

Full Application Compromise

If running with high privileges (as seen: root): Complete system control Data theft Persistence installation

If the application is running with high privileges (e.g., root), an attacker may gain the same level of access after successfully exploiting the vulnerability.

Impact

• carrying out random system commands
• Changing or removing program files
• Installing backdoors or harmful software
• command of the complete application environment

Successful exploitation of this vulnerability may lead to full application
compromise. If the application runs with elevated privileges (e.g., root),
an attacker could execute arbitrary commands on the server, resulting in
complete system control.

Secure Fix Recommendations:

• Allow only safe file types (e.g., JPG, PNG) using strict extension and MIME validation, and block executable files like .php, .jsp, etc.
• Store uploaded files outside the web root and serve them via a controlled endpoint or force download to prevent execution.
• Rename files and sanitize filenames (remove path traversal patterns) and disable script execution in the upload directory.
• Implement Strict File Type Validation The application should validate uploaded files using a whitelist approach for both file extensions and MIME types.

References:

File Upload — OWASP Cheat Sheet Series