File upload vulnerabilities: how uploads go wrong, how testers prove it, how to secure them

A file upload vulnerability is a flaw that lets an attacker store a file your application should have rejected. CWE-434 describes it as a product that "allows the upload or transfer of dangerous file types that are automatically processed within its environment." The result ranges from a defaced page to code running on your server, depending on what the app does with the file next.

Upload handling is part of web application penetration testing and API penetration testing. Testing needs written authorization from the system owner.

What is a file upload vulnerability, and what can it cause?#

A file upload vulnerability exists when an application accepts a file and then stores, serves or processes it in a way the attacker can abuse. The same weakness is called unrestricted file upload, arbitrary file upload or insecure file upload. Five outcomes matter:

PortSwigger's Web Security Academy describes the worst case as a web shell, a script that lets an attacker run commands through HTTP requests. The attacker needs two things: a way to upload the file, and a way to make the server run it.

How do uploads go wrong?#

Uploads go wrong when the application trusts something the client controls: the file name, the Content-Type header, the file's apparent type, or the upload folder's behavior. Each check below fails in a different way.

<?php
// Vulnerable: trusts the client's header and file name
if ($_FILES['avatar']['type'] === 'image/png') {
    move_uploaded_file($_FILES['avatar']['tmp_name'],
        '/var/www/html/uploads/' . $_FILES['avatar']['name']);
}

Which bypass classes should you expect?#

Attackers beat weak validation by changing the part of the upload that the check does not look at. This matrix lists the classes with the defense each one defeats. It leaves out payload strings, which the PortSwigger labs document.

OWASP's cheat sheet states the rule behind the first row: the Content-Type of an uploaded file "is provided by the user, and as such cannot be trusted, as it is trivial to spoof."

What can go wrong without remote code execution?#

Uploads cause serious harm without any code execution on the server. The brief list:

• Stored XSS through SVG or HTML files served from your origin. See cross-site scripting.
• XML external entity attacks if the app parses uploaded XML, Office files or SVG on the server.
• Server-side request forgery if a converter fetches URLs found inside the file. See SSRF.
• Parser bugs in image, PDF or document libraries. The two CVEs below are of this type.
• Path traversal through the file name or through archive entries.
• Disk, memory or CPU exhaustion from huge files or archive bombs.

How do you secure file uploads?#

Secure uploads in layers. No single check is enough. The OWASP File Upload Cheat Sheet lists the controls, and the sequence below puts them in order.

1. Check authorization before accepting the upload.
2. Allow only the extensions the feature needs (allow-list).
3. Set a maximum size and, for archives, a maximum number of entries.
4. Check the file content against the claimed type on the server.
5. Generate a random name. Never use the client's name for the stored path.
6. Store outside the web root, or in object storage on a separate domain.
7. Make sure the storage location cannot execute files.
8. Scan with antivirus where the files are shared with other users.
9. Serve with a fixed Content-Type, X-Content-Type-Options: nosniff, and Content-Disposition: attachment for downloads.

MDN explains that nosniff tells the browser to follow the declared Content-Type and not guess. OWASP gives two options for storage: keep files outside the web root where only administrative access is allowed, or keep them inside it with write-only permissions and strict read controls.

Node.js (multer and file-type)#

const multer = require("multer");
const crypto = require("node:crypto");
const fs = require("node:fs/promises");
const path = require("node:path");

const upload = multer({ dest: "/srv/uploads/tmp", limits: { fileSize: 5 * 1024 * 1024, files: 1 } });
const ALLOWED = { png: "image/png", jpg: "image/jpeg" };

app.post("/avatar", requireLogin, upload.single("avatar"), async (req, res) => {
  const { fileTypeFromFile } = await import("file-type");
  const detected = await fileTypeFromFile(req.file.path);
  if (!detected || !ALLOWED[detected.ext]) {
    await fs.unlink(req.file.path);
    return res.status(400).send("Unsupported file");
  }
  const name = crypto.randomUUID() + "." + detected.ext;
  await fs.rename(req.file.path, path.join("/srv/uploads/final", name));
  res.json({ id: name });
});

The code uses the detected type for the extension, so the client's name and header are never used.

Python (Flask and python-magic)#

import uuid, magic
from pathlib import Path

ALLOWED = {"image/png": "png", "image/jpeg": "jpg"}
app.config["MAX_CONTENT_LENGTH"] = 5 * 1024 * 1024

@app.post("/avatar")
@login_required
def avatar():
    f = request.files["avatar"]
    head = f.stream.read(2048)
    f.stream.seek(0)
    ext = ALLOWED.get(magic.from_buffer(head, mime=True))
    if not ext:
        abort(400)
    name = f"{uuid.uuid4()}.{ext}"
    f.save(Path("/srv/uploads/final") / name)
    return {"id": name}

Flask raises a 413 error when a request body exceeds MAX_CONTENT_LENGTH.

Java (Spring)#

@PostMapping("/avatar")
public Map<String, String> avatar(@RequestParam("avatar") MultipartFile file) throws IOException {
    if (file.getSize() > 5L * 1024 * 1024) throw new ResponseStatusException(HttpStatus.PAYLOAD_TOO_LARGE);
    byte[] head = file.getInputStream().readNBytes(16);
    String ext = sniff(head); // returns "png" or "jpg" from the magic bytes, or null
    if (ext == null) throw new ResponseStatusException(HttpStatus.BAD_REQUEST);
    String name = UUID.randomUUID() + "." + ext;
    Files.copy(file.getInputStream(), Paths.get("/srv/uploads/final").resolve(name));
    return Map.of("id", name);
}

A library such as Apache Tika can replace the sniff helper. Keep the allow-list on your side.

PHP (finfo)#

$allowed = ['image/png' => 'png', 'image/jpeg' => 'jpg'];
$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file($_FILES['avatar']['tmp_name']);
if (!isset($allowed[$mime]) || $_FILES['avatar']['size'] > 5 * 1024 * 1024) {
    http_response_code(400);
    exit;
}
$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
move_uploaded_file($_FILES['avatar']['tmp_name'], '/srv/uploads/final/' . $name);

The PHP manual says move_uploaded_file() checks that the file is a valid upload, meaning PHP received it through its HTTP POST upload mechanism.

Go#

func avatar(w http.ResponseWriter, r *http.Request) {
    r.Body = http.MaxBytesReader(w, r.Body, 5<<20)
    file, _, err := r.FormFile("avatar")
    if err != nil { http.Error(w, "bad upload", 400); return }
    defer file.Close()
    head := make([]byte, 512)
    n, _ := file.Read(head)
    ext := map[string]string{"image/png": "png", "image/jpeg": "jpg"}[http.DetectContentType(head[:n])]
    if ext == "" { http.Error(w, "unsupported", 400); return }
    file.Seek(0, io.SeekStart)
    id := uuid.NewString() + "." + ext
    out, _ := os.Create(filepath.Join("/srv/uploads/final", id))
    defer out.Close()
    io.Copy(out, file)
}

For images, re-encode the pixels with a maintained image library and discard the original bytes. That removes appended data and most polyglot tricks. Re-encoding does not protect against bugs in the library, so keep it patched.

Which storage and cloud controls matter?#

Storage decides how much damage a missed bug can do. The strongest design keeps uploaded files away from your application server and your main origin.

How do penetration testers detect and prove upload flaws?#

Testers prove an upload flaw by showing what the server did with the file, using a benign marker. Storage alone is not impact. Execution, script running in a browser, or an overwritten record is impact.

Our method follows OWASP WSTG-BUSL-09 and the Excession Labs evidence standard. Upload tests are bounded, the cost is stated in the report, and we use test-owned accounts. We never upload real malware or a persistent web shell.

Controls: upload a valid file as a baseline, upload a rejected type and record the error, and repeat the uploads as another account to check access control. Record the stored URL, the response headers, and the time of each request. Delete test files after the test and list them in the report.

Which real vulnerabilities involved crafted uploads?#

Both of the following CVEs involve a crafted image file reaching a parser, and NVD records each one.

Both show that a valid-looking image can attack the library behind the upload. Update image and document libraries, and process uploads with the least privilege you can.

File upload testing checklist#

1. List every upload point: forms, APIs, import features, avatar, attachments, and any PUT method.
2. Confirm scope and written authorization, and agree on file sizes for tests.
3. Upload a valid file and note the stored path, name, headers and who can read it.
4. Change the extension, the Content-Type and the content independently.
5. Check whether the file name controls the stored path.
6. Check whether the upload location executes files.
7. Open HTML and SVG files in a real browser to see whether script runs on your origin.
8. Test size, count and archive limits with small, agreed values.
9. Read the file back from a second account.
10. Remove test files, list them, and retest after the fix.

When should you get a professional test?#

Get a professional test when your product accepts files from customers, processes them with converters or image libraries, or lets users share files with each other. A scanner can check for a few known cases. It cannot tell what your pipeline does with a file after storage. Excession Labs tests uploads as part of web application penetration testing and API penetration testing, under a written scope.

Related guides: path traversal for file name attacks, and server-side request forgery for converters that fetch URLs.