Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When parsing application/x-www-form-urlencoded bodies, QuerystringParser located the field separator with a two step lookup: it first scanned the entire remaining buffer for &, and only when no & existed anywhere ahead did it fall back to scanning for ;. For a body that uses ; as the separator and contains no &, every field iteration performed a full failed & scan over the entire remaining buffer before locating the nearby ;. With N semicolon separated fields in a chunk of size B, this yields O(B^2) byte comparisons per chunk. An attacker can submit a small crafted body of the form a;a;a;... and cause the parser to spend seconds of CPU per request. A handful of concurrent requests can exhaust worker processes. Details In pythonmultipart/multipart.py, both the FIELDNAME and FIELDDATA states located the next separator like this: data.find(b"&", i) scans from i to the end of the buffer and returns -1 only when there is no & anywhere in the remainder. For a ; separated body with…
Recommended action: Upgrade to 0.0.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
parseform() did not validate the Content-Length header before using it to bound its chunked read of the request body. A negative Content-Length turned the bounded read into a read-until-EOF, so the entire body was loaded into memory in a single read instead of in fixed-size chunks. Details parseform() reads the input stream in chunks, never reading more than the remaining Content-Length at a time. The per-chunk size is computed as min(contentlength - bytesread, chunksize). The header value was parsed to an integer without checking its sign, so a Content-Length of -1 made this expression negative, and inputstream.read(-1) reads until end of stream. The intended bounded, chunked read therefore collapsed into a single unbounded read of the whole stream. The amount read is still bounded by what the client actually sends. Impact This only affects code that calls parseform() directly with a Content-Length header taken from attacker-controlled input and without normalizing a…
Recommended action: Upgrade to 0.0.31 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
QuerystringParser treated ; as a field separator in application/x-www-form-urlencoded bodies, in addition to &. The WHATWG URL standard, modern browsers, and Python's urllib.parse (since the CVE-2021-23336 fix) treat only & as a separator. This creates a parser differential: the same bytes are tokenized into different fields than a WHATWG compliant intermediary would produce, allowing an attacker to smuggle extra form fields past an upstream body inspecting component. Details In pythonmultipart/multipart.py, the FIELDNAME and FIELDDATA states located the next separator by scanning for & and, failing that, for ;: As a result, ; acted as a field boundary. Because the fallback only triggered when no & remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across write() calls. This is the same class of issue as CVE-2021-23336 in CPython's urllib.parse. For example, a body inspecting WAF or gateway that…
Recommended action: Upgrade to 0.0.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
parseoptionsheader 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 filename0/filename1 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. Details Given both a plain and an extended parameter, the extended value won. For example: An inspector following RFC 7578 sees the field comment, while the returned value was name=role. The same applies to filenames: The…
Recommended action: Upgrade to 0.0.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
python-multipart has a denial of service vulnerability in multipart part header parsing. When parsing multipart/form-data, MultipartParser previously had no limit on the number of part headers or the size of an individual part header. An attacker could send a request with either many repeated headers without terminating the header block or a single very large header value, causing excessive CPU work before request rejection or completion. Impact Applications that parse attacker-controlled multipart/form-data with affected versions of python-multipart can experience CPU exhaustion. ASGI applications using Starlette, FastAPI, or other frameworks that invoke python-multipart may have worker or event-loop delays while processing malicious upload requests. Details The affected parser states are HEADERFIELDSTART, HEADERFIELD, HEADERVALUESTART, HEADERVALUE, and HEADERVALUEALMOSTDONE. The issue can be triggered by: - A multipart part with an oversized individual header value. - A…
Recommended action: Upgrade to 0.0.27 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A denial of service vulnerability exists when parsing crafted multipart/form-data requests with large preamble or epilogue sections. Details Two inefficient multipart parsing paths could be abused with attacker-controlled input. Before the first multipart boundary, the parser handled leading CR and LF bytes inefficiently while searching for the start of the first part. After the closing boundary, the parser continued processing trailing epilogue data instead of discarding it immediately. As a result, parsing time could grow with the size of crafted data placed before the first boundary or after the closing boundary. Impact An attacker can send oversized malformed multipart bodies that consume excessive CPU time during request parsing, reducing request-handling capacity and delaying legitimate requests. This issue degrades availability but does not typically result in a complete denial of service for the entire application. Mitigation Upgrade to version 0.0.26 or later, which…
Recommended action: Upgrade to 0.0.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Path Traversal vulnerability exists when using non-default configuration options UPLOADDIR and UPLOADKEEPFILENAME=True. An attacker can write uploaded files to arbitrary locations on the filesystem by crafting a malicious filename. Details When UPLOADDIR is set and UPLOADKEEPFILENAME is True, the library constructs the file path using os.path.join(filedir, fname). Due to the behavior of os.path.join(), if the filename begins with a /, all preceding path components are discarded: This allows an attacker to bypass the intended upload directory and write files to arbitrary paths. Affected Configuration Projects are only affected if all of the following are true: - UPLOADDIR is set - UPLOADKEEPFILENAME is set to True - The uploaded file exceeds MAXMEMORYFILESIZE (triggering a flush to disk) The default configuration is not vulnerable. Impact Arbitrary file write to attacker-controlled paths on the filesystem. Mitigation Upgrade to version 0.0.22, or avoid using…
Recommended action: Upgrade to 0.0.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When parsing form data, python-multipart skips line breaks (CR \r or LF \n) in front of the first boundary and any tailing bytes after the last boundary. This happens one byte at a time and emits a log event each time, which may cause excessive logging for certain inputs. An attacker could abuse this by sending a malicious request with lots of data before the first or after the last boundary, causing high CPU load and stalling the processing thread for a significant amount of time. In case of ASGI application, this could stall the event loop and prevent other requests from being processed, resulting in a denial of service (DoS). Impact Applications that use python-multipart to parse form data (or use frameworks that do so) are affected. Original Report This security issue was reported by: - GitHub security advisory in Starlette on October 30 by @Startr4ck - Email to python-multipart maintainer on October 3 by @mnqazi
Recommended action: Upgrade to 0.0.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FastAPI is a web framework for building APIs with Python 3.8+ based on standard Python type hints. When using form data, `python-multipart` uses a Regular Expression to parse the HTTP `Content-Type` header, including options. An attacker could send a custom-made `Content-Type` option that is very difficult for the RegEx to process, consuming CPU resources and stalling indefinitely (minutes or more) while holding the main event loop. This means that process can't handle any more requests. It's a ReDoS(Regular expression Denial of Service), it only applies to those reading form data, using `python-multipart`. This vulnerability has been patched in version 0.109.1.
Recommended action: Upgrade to 0.0.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.