CVE-2026-24486

What it actually does

Python-Multipart versions prior to 0.0.22 can allow path traversal during multipart file upload handling when applications use the non-default combination of UPLOAD_DIR and UPLOAD_KEEP_FILENAME=True. In that configuration, a filename supplied in the multipart Content-Disposition header may be preserved and joined with the upload directory without sufficient normalization and containment checks. A remote unauthenticated attacker who can reach an upload endpoint can craft a filename containing traversal sequences or absolute-path behavior to write the uploaded file outside the intended upload directory. The primary impact is arbitrary file write with high integrity impact, with possible limited confidentiality and availability impact depending on what paths the application process can write to.

Why it matters to the business

Applications that accept file uploads using affected Python-Multipart configurations may allow outsiders to place or overwrite files on the server. This can lead to service disruption, tampering with application data, configuration changes, web shell placement in web-served directories, or later privilege escalation if sensitive writable paths are reachable by the application account. Although it is not currently listed in CISA KEV and EPSS is relatively low at 0.02228, public exploitability is reported, the issue is network-reachable, requires no authentication or user interaction, and has been public for 194 days, so internet-facing upload services should be treated as higher priority.

How an attack unfolds

An attacker first identifies an application endpoint that accepts multipart/form-data uploads and is backed by a vulnerable Python-Multipart version. Exploitation requires the application to have configured an upload directory while also preserving user-supplied filenames with UPLOAD_KEEP_FILENAME=True. The attacker submits a multipart upload where the filename parameter contains path traversal components or other path manipulation intended to escape the configured upload directory. If the application process has filesystem permission to the targeted path, the parser writes the uploaded content to that attacker-chosen location. The attacker may then use the written file to alter application behavior, overwrite data, plant content in a web-accessible directory, influence startup/configuration files, or create a foothold for further exploitation. The practical result depends heavily on process privileges, writable directories, framework routing, and whether uploaded content can later be executed or served.

How to fix it

Upgrade Python-Multipart to version 0.0.22 or later. For source-based deployments, ensure the fix corresponding to kludex/python-multipart commit bea7bbb2904da8ce39123a845088dc72464eaddf is included. For Chainguard vault-fips-1.21 and vault-fips-1.21-compat packages, rebuild or redeploy from vendor images/package revisions that include the fixed metadata shown as fixed in version 0. As an immediate workaround, disable filename preservation by avoiding UPLOAD_KEEP_FILENAME=True, or generate server-side filenames instead of trusting client-supplied names. Additionally, enforce canonical path validation after joining paths, reject filenames containing directory separators or traversal sequences, store uploads outside executable/web-served locations, run the application with least-privilege filesystem permissions, and restrict write access to only the intended upload directory.

How to confirm the fix worked

Confirm dependency resolution shows python-multipart version 0.0.22 or later in all application images, virtual environments, lockfiles, and build artifacts. Review application configuration for UPLOAD_KEEP_FILENAME=True and verify it is removed or paired with strict filename sanitization and path containment checks. Test upload endpoints with benign traversal-style filenames in a non-production environment and verify files are rejected or stored only inside the configured upload directory using a sanitized server-generated name. Validate container images and SBOMs no longer report vulnerable python-multipart versions. Confirm runtime filesystem permissions prevent the application account from writing to application code directories, configuration paths, startup directories, and web-served executable paths.

Typical attack path

1. Discover a web application or API endpoint that accepts multipart/form-data file uploads.
2. Determine or infer that the upload stack uses Python-Multipart before version 0.0.22 and preserves submitted filenames.
3. Send a crafted multipart request with a filename containing traversal or absolute-path manipulation.
4. Cause the application to write the uploaded content outside the intended UPLOAD_DIR.
5. Target a writable location that changes application behavior, stores attacker-controlled content, or disrupts service.
6. If possible, access or trigger the written file to gain persistence, execute code through another weakness, or continue lateral exploitation.

How to detect it

To determine whether exploitation already occurred, review web server, reverse proxy, application, and API gateway logs for multipart upload requests where the Content-Disposition filename value contains traversal patterns, encoded separators, absolute paths, or unusual operating-system path syntax. Focus on endpoints that accept file uploads and services using Python-Multipart before 0.0.22 with UPLOAD_KEEP_FILENAME=True. Inspect application logs for upload errors, filename normalization failures, permission errors, or unexpected destination paths. Perform filesystem forensics around upload timestamps: identify files created or modified outside the intended upload directory by the application service account, especially in application code directories, static/web-served directories, template directories, configuration directories, cron/systemd locations, temporary directories, and user home directories. Compare deployed files against known-good images or package manifests. Look for suspicious file types written through upload flows, including scripts, templates, server-side code, configuration files, archives, and files with double extensions. If containers are used, review container filesystem diffs and rebuild rather than relying only on in-place cleanup. Correlate suspicious upload requests with subsequent HTTP requests to newly written paths, process launches, configuration reloads, authentication anomalies, or outbound network connections.

• UPLOAD_KEEP_FILENAME=True
• python-multipart==0.0.21
• python-multipart==0.0.20
• python-multipart==0.0.19
• python-multipart==0.0.18
• python-multipart==0.0.17
• python-multipart==0.0.16
• python-multipart==0.0.15
• python-multipart==0.0.14
• python-multipart==0.0.13
• python-multipart==0.0.12
• python-multipart==0.0.11
• python-multipart==0.0.10
• Content-Disposition: form-data;
• filename="../
• filename="..\\
• filename=../
• filename=..\\
• %2e%2e%2f
• %2e%2e%5c
• ..%2f
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• filename="/etc/
• filename="/var/
• filename="/tmp/
• filename="C:\\
• filename="\\\\
• ../
• ..\\
• /etc/cron.d/
• /etc/systemd/system/
• /var/www/
• /usr/share/nginx/html/
• /app/
• /opt/
• /root/.ssh/authorized_keys
• .php
• .phtml
• .jsp
• .jspx
• .aspx
• .py
• .sh
• .service
• .conf

What your security team should do

• Prioritize remediation for internet-facing services, APIs, and administrative portals that accept file uploads using Python-Multipart.
• Inventory applications and containers for python-multipart versions prior to 0.0.22, including transitive dependencies in Python web frameworks and packaged products.
• Search code and configuration repositories for UPLOAD_KEEP_FILENAME=True and treat any match as exposure until proven otherwise.
• Upgrade to python-multipart 0.0.22 or later and redeploy affected services from clean builds.
• Add upload security controls: server-generated filenames, extension/content validation, path canonicalization, storage outside web roots, malware scanning, and least-privilege write permissions.
• Review historical upload logs and filesystem changes for traversal-style filenames or unexpected writes outside upload directories.
• Add WAF, reverse proxy, or application logging rules to alert on multipart filename parameters containing path traversal indicators.
• If suspicious writes are found, perform incident response: preserve logs, hash suspicious files, check for web shells or modified configuration, rotate affected secrets, and rebuild compromised hosts or containers.