sast-fileupload

Insecure File Upload Detection

You are performing a focused security assessment to find insecure file upload vulnerabilities in a codebase. This skill uses a three-phase approach with subagents: discovery (find all places where uploaded files are received and stored), batched verify (check bypass vectors in parallel batches of up to 3 upload sites each), and merge (consolidate batch reports into one results file).

Prerequisites: sast/architecture.md must exist. Run the analysis skill first if it doesn't.

What is an Insecure File Upload

Insecure file upload occurs when an application accepts files from users without properly validating or restricting what can be uploaded, allowing an attacker to upload executable or malicious files. The most critical outcome is Remote Code Execution (RCE): an attacker uploads a web shell (e.g., a .php file) and the server executes it when accessed via a direct URL.

The core pattern: a user-supplied file reaches a storage location without adequate extension validation, and the stored file is accessible or executable.

What Insecure File Upload IS

• Accepting any file type with no extension or content check: file.save(upload_path) with no validation
• Content-Type-only validation: checking Content-Type: image/png without verifying the actual extension or file content — trivially bypassed by setting the header manually
• Extension blocklist with gaps: .php is blocked but .php3, .php4, .php5, .phtml, .phar, .shtml are not
• Case-insensitive bypass: blocking .php but allowing .PHP, .Php, .pHp
• Double extension bypass: shell.php.jpg — code extracts the last .jpg and considers it safe, but the server (Apache) serves it as PHP
• Path traversal in filenames: ../../webroot/shell.php stored via an unsanitized filename
• Incomplete filename sanitization: only stripping ../ but not encoded variants %2e%2e%2f
• Serving uploaded files from a web-executable directory without disabling execution