Description

Flask-Reuploaded provides file uploads for Flask. From 1.5.0 until 1.6.0, UploadSet.save(storage, name=...) in src/flask_uploads/flask_uploads.py applies lowercase_ext to the default upload path but uses the case-preserving extension helper for a caller-supplied name before extension_allowed evaluates an AllExcept denylist. An attacker who controls the name override can use a mixed-case dangerous extension to bypass a lowercase denylist and store the file in the served upload directory. Exploitation requires a denylist configuration, a user-influenced name override, and a deployment that resolves or executes extensions case-insensitively; pure allowlists remain protected and path containment is not bypassed. On an execution-capable upload directory, the stored file can execute with the web server's privileges and affect confidentiality, integrity, and availability. This issue is fixed in version 1.6.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T18:17:53.547Z",
  "pubdate": "2026-09-14T18:17:53.547Z",
  "executiveSummary": "Flask-Reuploaded versions 1.5.0 through 1.6.0 contain a critical file upload validation vulnerability involving an inconsistent extension handling mechanism.\nThe vulnerability occurs due to a discrepancy between how the system processes extensions for default paths versus caller-supplied file names, enabling attackers to circumvent security-critical extension denylists.\nBy providing a mixed-case malicious file extension in an overridden upload name, an attacker can bypass filters that only check for lowercase equivalents.\nSuccessful exploitation requires specific conditions: the application must use a denylist-based validation configuration, accept user-influenced name overrides for file uploads, and operate on an execution-capable directory (e.g., a web-root directory that executes server-side code).\nIf the target environment resolves or executes extensions in a case-insensitive manner, an attacker can successfully upload and execute arbitrary code with the web server's service privileges.\nThis represents a significant threat to confidentiality, integrity, and availability, potentially leading to full system compromise depending on the server configuration.",
  "technicalDetails": "The vulnerability resides within the UploadSet.save function in src/flask_uploads/flask_uploads.py. The root cause is a logic inconsistency in how the extension of a file is normalized during validation versus storage.\nIn the vulnerable versions, when a caller provides a custom filename via the 'name' parameter, the system employs a case-preserving helper to extract the file extension. However, the subsequent security check, 'extension_allowed', evaluates this extension against a denylist. Because the validation logic fails to enforce consistent case normalization (such as forcing the extension to lowercase) before performing the denylist lookup, it creates an opportunity for bypass.\nSpecifically, when 'extension_allowed' uses an 'AllExcept' (denylist) approach, an attacker can supply a filename with a mixed-case extension—for example, '.PhP' instead of '.php'. If the denylist only contains lowercase entries, the check will fail to identify the malicious extension as blocked. Consequently, the file is saved to the target directory with its dangerous, mixed-case extension intact.\nExploitation flow: 1. The attacker identifies an application endpoint using 'Flask-Reuploaded' that accepts user-supplied names for file saves and employs an 'AllExcept' extension validation policy. 2. The attacker crafts a request containing a malicious payload disguised with a mixed-case extension (e.g., 'shell.AsPx'). 3. The 'UploadSet.save' function extracts the extension, bypasses the case-sensitive denylist due to the discrepancy in normalization, and persists the file to the server's upload directory. 4. If the server is configured to execute files with that extension (common in environments where web-root directories are used for uploads), the attacker requests the file directly. 5. The server executes the uploaded payload under the security context of the web application service, granting the attacker arbitrary code execution capabilities.\nThis issue only affects environments using denylists, as pure allowlists are structurally protected against this bypass. Furthermore, path containment is not compromised; the vulnerability is strictly related to file type filter bypass and subsequent execution risks."
}