Bug 2494100

Summary: CVE-2026-53537 python-multipart: Python-Multipart: Information disclosure via header parsing discrepancy [epel-all]
Product: [Fedora] Fedora EPEL Reporter: Ganesh <gnaik>
Component: python-python-multipartAssignee: Ben Beasley <code>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: epel10CC: carlwgeorge, code, cstratak, python-packagers-sig
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: {"flaws": ["7914e0a0-4fe7-4db4-9e13-daeb6c06a496"]}
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-06-29 08:00:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2491460    

Description Ganesh 2026-06-29 07:33:41 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.30, parse_options_header parsed Content-Disposition (and Content-Type) headers with email.message.Message, which transparently applies RFC 2231/5987 decoding. The extended parameter syntax (filename*=charset'lang'value, name*=..., and the filename*0/filename*1 continuation form) is decoded and surfaced under the bare filename/name key, and overrides the plain parameter when both are present. RFC 7578 §4.2 explicitly forbids the filename* form in multipart/form-data. Components that follow RFC 7578, or that do not implement RFC 2231/5987 decoding for multipart/form-data (WAFs, proxies, gateways), may interpret such a header differently. An attacker can exploit that difference to smuggle a different field name or filename past an upstream inspector to the backend. This vulnerability is fixed in 0.0.30.

Comment 1 Ben Beasley 2026-06-29 08:00:52 UTC
This CVE refers to a different package, which is already at a version containing the fix in EPEL10. The EPEL9 branch is affected, but an incompatible update would be required, the necessary changes aren’t quite trivial to backport, and the low severity of this CVE does not appear to justify requesting an Updates Policy exception and coordinating an incompatible update.