What <code>multipart/form-data</code>, client-side controls, and one very confusing successful upload taught me about acceptance versus execution.
I had worked with real file uploads before studying this vulnerability.
From a frontend perspective, the flow felt familiar:
<pre><code>choose a file
validate type and size
show a preview
send it to the backend
display success or an error
</code></pre>
The allowed types might start as a list:
<pre><code>const acceptedTypes = [&quot;image/jpeg&quot;, &quot;image/png&quot;, &quot;image/webp&quot;];
</code></pre>
Then become an <code>accept</code> value or Dropzone configuration.
I saw that list as a control, not a serious security boundary: useful for guiding users and producing better validation messages.
What I had not explored deeply was what happened after the browser sent the file.
That is where File Upload vulnerabilities begin.
<blockquote>
The important question is not only “Can I upload this file?” It is “What does the application do with it next?”
</blockquote>
<h2>The UI is only the first layer</h2>
A typical input may look like this:
<pre><code>&lt;input
 type=&quot;file&quot;
 accept=&quot;image/jpeg,image/png,image/webp&quot;
/&gt;
</code></pre>
This is valuable for UX, but the browser is controlled by the user.
An attacker can modify the request in Burp, send it directly with another tool, change the filename or file part <code>Content-Type</code>, and replace the content after client-side validation.
The frontend can help honest users choose a valid file. It cannot prove to the server that the uploaded bytes are safe.
Frontend validation is worth building, but it should never be confused with server-side enforcement.
<h2>What the browser actually sends</h2>
<img src="https://media.daily.dev/image/upload/s--rq5FaYAo--/f_auto/v1782133647/ugc/content_d8070d86-5a52-410a-a26c-9cbb6ca644cd?_a=BAMAMiWQ0" alt="35acc5b8-d15d-4d1d-9545-d213297e4e25.png">
Most browser uploads use <code>multipart/form-data</code>.
The request body is split into parts using a boundary:
<pre><code>POST /my-account/avatar HTTP/2
Host: example.com
Content-Type: multipart/form-data; boundary=----upload-boundary

------upload-boundary
Content-Disposition: form-data; name=&quot;avatar&quot;; filename=&quot;profile.php&quot;
Content-Type: image/png

&lt;?php echo &quot;UPLOAD_TEST&quot;; ?&gt;
------upload-boundary--
</code></pre>
There are several different values here:
<pre><code>name=&quot;avatar&quot; -&gt; form field name
filename=&quot;profile.php&quot; -&gt; client-supplied filename
Content-Type: image/png -&gt; client-supplied type
file body -&gt; client-supplied bytes
</code></pre>
The top-level <code>Content-Type</code> describes the complete request; the file part has its own headers.
Looking at the raw request made one thing clear: the browser sends a collection of user-controlled claims about a file.
The server still has to verify those claims.
<h2><code>Content-Type</code> is a hint, not proof</h2>
Suppose the application accepts only JPEG and PNG images.
A PHP file may initially be sent as:
<pre><code>Content-Type: application/octet-stream
</code></pre>
and rejected with:
<pre><code>Only image/jpeg and image/png are allowed
</code></pre>
Changing only the multipart header to this:
<pre><code>Content-Type: image/png
</code></pre>
may be enough to bypass a weak check.
The file did not magically become a PNG. The attacker changed a text header inside the request.
MIME type and extension checks make sense as controls, but not as complete security. They are useful signals that cannot be trusted independently.
<h2>Upload accepted does not mean exploit successful</h2>
This was the part that gave me a genuine “WTF?” moment.
I uploaded a dangerous-looking file. The application accepted it. I found the URL. Then I requested it, and nothing useful happened.
My reaction was basically:
<blockquote>
It passed. Why does it not work?
</blockquote>
The answer was that upload acceptance and code execution are separate conditions.
An uploaded file may be:
<ul>
<li>rejected before storage;</li>
<li>renamed by the backend;</li>
<li>stored outside the public web root;</li>
<li>returned as a download;</li>
<li>rendered as an image;</li>
<li>served as plain text;</li>
<li>processed by another service;</li>
<li>interpreted as executable server-side code.</li>
</ul>
For example:
<pre><code>shell.php -&gt; rejected
shell.php7 -&gt; accepted, but served as source text
shell.l33t -&gt; accepted and executed after server configuration changed
</code></pre>
Getting a file through the filter is only one step.
After every accepted upload, I now want to know:
<pre><code>What was the final filename?
Where was it stored?
What URL serves it?
What Content-Type comes back?
Is authentication required?
Is it downloaded, displayed, parsed, or executed?
</code></pre>
Retrieval behaviour helps decide whether the result is harmless storage, information disclosure, stored XSS, or remote code execution.
<h2>The simplest RCE case</h2>
<img src="https://media.daily.dev/image/upload/s--qSnEYi1o--/f_auto/v1782133675/ugc/content_08686fad-7c1f-44d8-b3a8-d9347b53588a?_a=BAMAMiWQ0" alt="db57675a-84a6-4bd9-9b1f-cd8679f9df0e.png">
The most direct lab accepted a PHP web shell and stored it in a web-accessible avatar directory.
The uploaded file could then be requested like this:
<pre><code>GET /files/avatars/shell.php?cmd=whoami
</code></pre>
The dangerous combination was:
<pre><code>attacker-controlled server-side code
 +
web-accessible storage
 +
PHP execution enabled in that directory
</code></pre>
The critical mistake was allowing an untrusted file to reach a location where the web server executed it as code.
This varies by stack. Uploading <code>.js</code> into a typical Node.js static directory does not automatically make Node execute it; the risks may instead include unsafe serving, stored XSS, path traversal, overwrite, or vulnerable processing.
The question is not “Is this extension dangerous everywhere?”
The question is:
<blockquote>
How will this specific application and server handle the final stored file?
</blockquote>
<h2>File uploads have more than one impact</h2>
Remote code execution is the dramatic case, but uploads can also lead to:
<ul>
<li>stored XSS through HTML or SVG served inline;</li>
<li>overwrite through unsafe filenames;</li>
<li>path traversal during storage;</li>
<li>information disclosure through public or predictable URLs;</li>
<li>availability or parser attacks through huge or malformed files.</li>
</ul>
This is why “we block PHP” is not a file upload security strategy.
<h2>A better black-box workflow</h2>
<img src="https://media.daily.dev/image/upload/s--J5JK5qag--/f_auto/v1782133685/ugc/content_aa1a7a14-bf01-4f17-b780-8773358ce8de?_a=BAMAMiWQ0" alt="8f2d6ee9-27cc-4496-ac46-da1cac5778f3.png">
The most useful testing workflow was not “start with a web shell”.
It was enumeration:
<ol>
<li>Upload a harmless valid file.</li>
<li>Inspect the multipart request.</li>
<li>Record the final name, URL, and response type.</li>
<li>Check whether the backend renamed it.</li>
<li>Compare accepted and rejected variations.</li>
<li>Separate storage from retrieval and execution.</li>
</ol>
A baseline image tells you how the normal feature works. Only then do bypass tests have context.
That felt much closer to debugging than to randomly throwing payloads at a form—and as a frontend engineer, debugging a data flow is a very familiar place to start.
<h2>Where the frontend still matters</h2>
Saying that frontend validation is not a security boundary does not mean it is useless.
The frontend should still guide file selection, explain limits, avoid rendering untrusted active content, handle rejection safely, preserve accessibility, and never claim a file is safe only because the UI accepted it.
The server owns the final security decision.
The frontend owns a clear, predictable, and safe user experience around that decision.
<h2>Summary</h2>
A file upload is not just a file input and a successful API response.
It is a pipeline:
<pre><code>selection -&gt; request -&gt; validation -&gt; storage -&gt; retrieval -&gt; processing
</code></pre>
Every stage can change the outcome.
A file can pass validation yet remain static text. Another becomes dangerous because the server stores it under an executable name in an executable location.
In Part 2, I will look at why upload filters keep failing: spoofed MIME types, double extensions, null-byte-style filename handling, magic bytes, polyglot files, Apache <code>.htaccess</code>, and safer upload architecture.
<h2></h2>
#appsec #security #cybersecurity #file #backend #frontend

Przemyslaw

File upload vulnerabilities go far beyond what the browser's file input accepts. The multipart/form-data format exposes that every value — filename, Content-Type, and file bytes — is user-controlled and untrustworthy. A weak server-side check on the MIME type header alone can be bypassed by simply changing that header. Crucially, a successful upload does not equal a successful exploit: the file must also be stored in a web-accessible location and executed by the server. The post walks through the simplest PHP web shell RCE scenario, explains how upload acceptance and code execution are separate conditions, and outlines a methodical black-box testing workflow. Beyond RCE, file uploads can also lead to stored XSS, path traversal, file overwrite, and information disclosure. Part 2 will cover filter bypass techniques including spoofed MIME types, double extensions, magic bytes, and polyglot files.

Key Web Vulnerabilities #7, Part 1: File Upload Is Not Just a File Input