Update dependency python-multipart to v0.0.31 [SECURITY] by renovate[bot] · Pull Request #13 · NavyStack/gnuboard-g6

renovate · 2024-08-12T05:32:06Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
python-multipart (changelog)	`==0.0.6` → `==0.0.31`

python-multipart vulnerable to Content-Type Header ReDoS

CVE-2024-24762 / GHSA-2jv5-9r88-3w3p

More information

Details

Summary

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.

This can create a ReDoS (Regular expression Denial of Service): https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

This only applies when the app uses form data, parsed with python-multipart.

Details

A regular HTTP Content-Type header could look like:

Content-Type: text/html; charset=utf-8

python-multipart parses the option with this RegEx: https://github.com/andrew-d/python-multipart/blob/d3d16dae4b061c34fe9d3c9081d9800c49fc1f7a/multipart/multipart.py#L72-L74

A custom option could be made and sent to the server to break it with:

Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

PoC

Create a simple WSGI application, that just parses the Content-Type, and run it with python main.py:

##### main.py
from wsgiref.simple_server import make_server
from wsgiref.validate import validator

from multipart.multipart import parse_options_header

def simple_app(environ, start_response):
    _, _ = parse_options_header(environ["CONTENT_TYPE"])

    start_response("200 OK", [("Content-type", "text/plain")])
    return [b"Ok"]

httpd = make_server("", 8123, validator(simple_app))
print("Serving on port 8123...")
httpd.serve_forever()

Then send the attacking request with:

$ curl -v -X 'POST' -H $'Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' --data-binary 'input=1' 'http://localhost:8123/'

Impact

This is a ReDoS, (Regular expression Denial of Service), so it only applies to those using python-multipart to read form data, such as Starlette and FastAPI.

Original Report

This was originally reported to FastAPI as an email to security@tiangolo.com, sent via https://huntr.com/, the original reporter is Marcello, https://github.com/byt3bl33d3r

Original report to FastAPI

Hey Tiangolo!

My name's Marcello and I work on the ProtectAI/Huntr Threat Research team, a few months ago we got a report (from @nicecatch2000) of a ReDoS affecting another very popular Python web framework. After some internal research, I found that FastAPI is vulnerable to the same ReDoS under certain conditions (only when it parses Form data not JSON).

Here are the details: I'm using the latest version of FastAPI (0.109.0) and the following code:

from typing import Annotated
from fastapi.responses import HTMLResponse
from fastapi import FastAPI,Form
from pydantic import BaseModel

class Item(BaseModel):
    username: str

app = FastAPI()

@app.get("/", response_class=HTMLResponse)
async def index():
    return HTMLResponse("Test", status_code=200)

@app.post("/submit/")
async def submit(username: Annotated[str, Form()]):
    return {"username": username}

@app.post("/submit_json/")
async def submit_json(item: Item):
    return {"username": item.username}

I'm running the above with uvicorn with the following command:

uvicorn server:app

Then run the following cUrl command:

curl -v -X 'POST' -H $'Content-Type: application/x-www-form-urlencoded; !=\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\' --data-binary 'input=1' 'http://localhost:8000/submit/'

You'll see the server locks up, is unable to serve anymore requests and one CPU core is pegged to 100%

You can even start uvicorn with multiple workers with the --workers 4 argument and as long as you send (workers + 1) requests you'll completely DoS the FastApi server.

If you try submitting Json to the /submit_json endpoint with the malicious Content-Type header you'll see it isn't vulnerable. So this only affects FastAPI when it parses Form data.

Cheers

Impact

An attacker is able to cause a DoS on a FastApi server via a malicious Content-Type header if it parses Form data.

Occurrences

params.py L586

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Denial of service (DoS) via deformation `multipart/form-data` boundary

CVE-2024-53981 / GHSA-59g5-xgcq-4qw3

More information

Details

Summary

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

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Python-Multipart has Arbitrary File Write via Non-Default Configuration

CVE-2026-24486 / GHSA-wp53-j4wj-2cfg

More information

Details

Summary

A Path Traversal vulnerability exists when using non-default configuration options UPLOAD_DIR and UPLOAD_KEEP_FILENAME=True. An attacker can write uploaded files to arbitrary locations on the filesystem by crafting a malicious filename.

Details

When UPLOAD_DIR is set and UPLOAD_KEEP_FILENAME is True, the library constructs the file path using os.path.join(file_dir, fname). Due to the behavior of os.path.join(), if the filename begins with a /, all preceding path components are discarded:

os.path.join("/upload/dir", "/etc/malicious") == "/etc/malicious"

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:

UPLOAD_DIR is set
UPLOAD_KEEP_FILENAME is set to True
The uploaded file exceeds MAX_MEMORY_FILE_SIZE (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 UPLOAD_KEEP_FILENAME=True in project configurations.

Severity

CVSS Score: 8.6 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

python-multipart affected by Denial of Service via large multipart preamble or epilogue data

CVE-2026-40347 / GHSA-mj87-hwqh-73pj

More information

Details

Summary

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 skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

python-multipart has Denial of Service via unbounded multipart part headers

CVE-2026-42561 / GHSA-pp6c-gr5w-3c5g

More information

Details

Summary

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 HEADER_FIELD_START, HEADER_FIELD, HEADER_VALUE_START, HEADER_VALUE, and HEADER_VALUE_ALMOST_DONE. The issue can be triggered by:

A multipart part with an oversized individual header value.
A multipart part with many repeated header lines or an unterminated header block.

Both variants are addressed by enforcing default parser limits for maximum header count and maximum header size.

Mitigation

Upgrade to python-multipart 0.0.27 or later.

If upgrading is not immediately possible, reduce exposure by enforcing request body size limits at the server, proxy, or framework layer. This is only a mitigation; affected versions of python-multipart still parse multipart part headers without the default header count and header size limits.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

python-multipart: Content-Disposition parameter smuggling via RFC 2231/5987 extended parameters

CVE-2026-53537 / GHSA-vffw-93wf-4j4q

More information

Details

Summary

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.

Details

Given both a plain and an extended parameter, the extended value won. For example:

Content-Disposition: form-data; name="comment"; name*=utf-8''role

An inspector following RFC 7578 sees the field comment, while the returned value was name=role. The same applies to filenames:

Content-Disposition: form-data; name="upload"; filename="safe.txt"; filename*=utf-8''evil.php

The inspector sees safe.txt, while the returned value was filename=evil.php. Continuation parameters (filename*0, filename*1, and so on) were likewise reassembled into a filename invisible to a plain filename= match, and percent encoded sequences in the extended value were decoded (so ..%2F, %00, and similar appeared in the returned filename).

This affects the high level parse_options_header, FormParser, create_form_parser, and parse_form APIs, and reaches Starlette/FastAPI through request.form(), where the smuggled value is exposed as the form field name or UploadFile.filename.

Impact

This is an interpretation conflict (CWE-436) with other multipart/form-data parsers. An attacker able to submit multipart/form-data can present a different field name or filename to an upstream body inspecting component than the one delivered to the application. Concrete consequences depend on how the application uses these values, and may include bypassing a field name or filename based access/upload control, or, for an application that builds filesystem paths from the parsed filename without sanitization, path traversal via decoded ..%2F sequences. Decoded control bytes such as %00 can likewise cause confusion between an upstream validator and the backend. The File class applies os.path.basename, so file writing through it is not directly affected.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which ignores RFC 2231/5987 extended parameters (name*, filename*, and their continuations) so the plain name/filename parameter remains authoritative. RFC 7578 §4.2 forbids filename* for multipart/form-data; name* and the continuation forms are dropped for the same reason, since they are not valid multipart/form-data parameters either.

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

python-multipart: Semicolon treated as querystring field separator enables parameter smuggling

CVE-2026-53538 / GHSA-6jv3-5f52-599m

More information

Details

Summary

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 python_multipart/multipart.py, the FIELD_NAME and FIELD_DATA states located the next separator by scanning for & and, failing that, for ;:

sep_pos = data.find(b"&", i)
if sep_pos == -1:
    sep_pos = data.find(b";", i)

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 follows the WHATWG rule (only & separates fields) receives:

role=user&x=;role=admin

The upstream parses two fields, role=user and x=";role=admin", sees a benign role=user, and forwards the request. QuerystringParser parsed the same bytes as three fields: role="user", x="", and role="admin". The application (for example via Starlette/FastAPI request.form(), where the last value wins) then received role=admin, a value the upstream validator never saw.

The parser is reachable through the public QuerystringParser class, the high level FormParser, create_form_parser, and parse_form APIs, and Starlette/FastAPI request.form() for url encoded bodies.

Impact

Interpretation conflict / HTTP parameter pollution. An attacker can smuggle extra or overriding form fields past an upstream component that applies the WHATWG separator rule, reaching the backend with parameters the intermediary did not observe.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which treats only & as a field separator per the WHATWG URL standard. ; is parsed as ordinary field data, matching urllib.parse, browsers, and other compliant parsers.

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

python-multipart: Quadratic-time querystring parsing with semicolon separators causes CPU denial of service

CVE-2026-53539 / GHSA-5rvq-cxj2-64vf

More information

Details

Summary

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 python_multipart/multipart.py, both the FIELD_NAME and FIELD_DATA states located the next separator like this:

sep_pos = data.find(b"&", i)
if sep_pos == -1:
    sep_pos = data.find(b";", i)

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 no &, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.

For example, a 1 MiB url encoded body consisting of a; repeated ~500,000 times, submitted with Content-Type: application/x-www-form-urlencoded, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of CPU for a single request. Cost scales quadratically with chunk size.

The parser is reachable through the public QuerystringParser class and through the high level FormParser, create_form_parser, and parse_form APIs for url encoded bodies. It is also the parser Starlette and FastAPI use for application/x-www-form-urlencoded request bodies via request.form().

Impact

Uncontrolled CPU consumption (denial of service). Parsing is synchronous, so a single small crafted form body occupies the handling worker for seconds, blocking any other work on that worker until parsing finishes. Sustained concurrent requests keep workers continuously busy, degrading or denying service.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which treats only & as a field separator (per the WHATWG URL standard) using a single bounded scan, making parsing linear in the body length.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

python-multipart: Negative Content-Length in parse_form buffers the entire body in memory

CVE-2026-53540 / GHSA-v9pg-7xvm-68hf

More information

Details

Summary

parse_form() 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

parse_form() 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(content_length - bytes_read, chunk_size). The header value was parsed to an integer without checking its sign, so a Content-Length of -1 made this expression negative, and input_stream.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 parse_form() directly with a Content-Length header taken from attacker-controlled input and without normalizing a negative value first. No known package is affected:

Starlette and FastAPI drive MultipartParser directly from the ASGI receive() stream and do not call parse_form().
Known parse_form() consumers either do not forward Content-Length to it, recompute it from the already-read body, or run behind a layer (such as Werkzeug) that normalizes a negative Content-Length to 0.

The realistic exposure is limited to bespoke WSGI or http.server handlers that forward raw client headers into parse_form(). In that case a crafted request buffers the body in memory at once, degrading availability under concurrent requests rather than causing a complete denial of service.

Mitigation

Upgrade to version 0.0.31 or later, which rejects a negative Content-Length with a ValueError before reading the stream.

Severity

CVSS Score: 3.7 / 10 (Low)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

Kludex/python-multipart (python-multipart)

`v0.0.31`

Compare Source

Speed up multipart header parsing and callback dispatch #295.
Bound header field name size before validating #296.
Validate Content-Length is non-negative in parse_form #297.

`v0.0.30`

Compare Source

Parse application/x-www-form-urlencoded bodies per the WHATWG URL standard, treating only & as a field separator #290.
Ignore RFC 2231/5987 extended parameters (name*, filename*) in parse_options_header, keeping the plain parameter authoritative per RFC 7578 §4.2 #291.

`v0.0.29`

Compare Source

Handle malformed RFC 2231 continuations in parse_options_header #270.

`v0.0.28`

Compare Source

Speed up partial-boundary tail scan via bytes.find #281.
Cap multipart boundary length at 256 bytes #282.

`v0.0.27`

Compare Source

Add multipart header limits #267.
Pass parse offsets via constructors #268.

`v0.0.26`

Compare Source

Skip preamble before the first multipart boundary more efficiently #262.
Silently discard epilogue data after the closing multipart boundary #259.

`v0.0.25`

Compare Source

Add MIME content type info to File #143.
Handle CTE values case-insensitively #258.
Remove custom FormParser classes #257.
Add UPLOAD_DELETE_TMP to FormParser config #254.
Emit field_end for trailing bare field names on finalize #230.
Handle multipart headers case-insensitively #252.
Apply Apache-2.0 properly #247.

`v0.0.24`

Compare Source

Validate chunk_size in parse_form() #244.

`v0.0.23`

Compare Source

Remove unused trust_x_headers parameter and X-File-Name fallback #196.
Return processed length from QuerystringParser._internal_write #229.
Cleanup metadata dunders from __init__.py #227.

`v0.0.22`

Compare Source

Drop directory path from filename in File 9433f4b.

`v0.0.21`

Compare Source

Add support for Python 3.14 and drop EOL 3.8 and 3.9 #216.

`v0.0.20`

Compare Source

Handle messages containing only end boundary #142.

`v0.0.19`

Compare Source

Don't warn when CRLF is found after last boundary on MultipartParser #193.

`v0.0.18`

Compare Source

Hard break if found data after last boundary on MultipartParser #189.

`v0.0.17`

Compare Source

Handle PermissionError in fallback code for old import name #182.

`v0.0.16`

Compare Source

Add dunder attributes to multipart package #177.

`v0.0.15`

Compare Source

Replace FutureWarning to PendingDeprecationWarning #174.
Add missing files to SDist #171.

`v0.0.14`

Compare Source

Fix import scheme for multipart module (#168).

`v0.0.13`

Compare Source

Rename import to python_multipart #166.

`v0.0.12`

Compare Source

Improve error message when boundary character does not match #124.
Add mypy strict typing #140.
Enforce 100% coverage #159.

`v0.0.11`

Compare Source

Improve performance, especially in data with many CR-LF #137.
Handle invalid CRLF in header name #141.

`v0.0.10`

Compare Source

Support on_header_begin #103.
Improve type hints on FormParser #104.
Fix OnFileCallback type #106.
Improve type hints #110.
Improve type hints on File #111.
Add type hint to helper functions #112.
Minor fix for Field.repr #114.
Fix use of chunk_size parameter #136.
Allow digits and valid token chars in headers #134.
Fix headers being carried between parts #135.

`v0.0.9`

Compare Source

Add support for Python 3.12 #85.
Drop support for Python 3.7 #95.
Add MultipartState(IntEnum) #96.
Add QuerystringState #97.
Add TypedDict callbacks #98.
Add config TypedDicts #99.

`v0.0.8`

Compare Source

Check if Message.get_params return 3-tuple instead of str on parse_options_header #79.
Cleanup unused regex patterns #82.

`v0.0.7`

Compare Source

Refactor header option parser to use the standard library instead of a custom RegEx #75.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

renovate Bot force-pushed the renovate/pypi-python-multipart-vulnerability branch from 622c2a4 to 31220d6 Compare December 4, 2024 05:50

renovate Bot changed the title ~~chore(deps): update dependency python-multipart to v0.0.7 [security]~~ chore(deps): update dependency python-multipart to v0.0.18 [security] Dec 4, 2024

renovate Bot force-pushed the renovate/pypi-python-multipart-vulnerability branch from 31220d6 to 6c78b44 Compare July 27, 2025 12:03

renovate Bot force-pushed the renovate/pypi-python-multipart-vulnerability branch 2 times, most recently from 920e018 to dc91891 Compare August 27, 2025 00:15

renovate Bot force-pushed the renovate/pypi-python-multipart-vulnerability branch from dc91891 to 001ff52 Compare January 27, 2026 03:44

renovate Bot changed the title ~~chore(deps): update dependency python-multipart to v0.0.18 [security]~~ chore(deps): update dependency python-multipart to v0.0.22 [security] Jan 27, 2026

renovate Bot changed the title ~~chore(deps): update dependency python-multipart to v0.0.22 [security]~~ Update dependency python-multipart to v0.0.22 [SECURITY] Apr 15, 2026

renovate Bot force-pushed the renovate/pypi-python-multipart-vulnerability branch from 001ff52 to 759e741 Compare August 16, 2026 08:08

Update dependency python-multipart to v0.0.31 [SECURITY]

ebc8881

renovate Bot force-pushed the renovate/pypi-python-multipart-vulnerability branch from 759e741 to ebc8881 Compare August 29, 2026 06:56

renovate Bot changed the title ~~Update dependency python-multipart to v0.0.22 [SECURITY]~~ Update dependency python-multipart to v0.0.31 [SECURITY] Aug 29, 2026

Navigation Menu

Update dependency python-multipart to v0.0.31 [SECURITY] - #13

Update dependency python-multipart to v0.0.31 [SECURITY]#13
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-python-multipart-vulnerability

renovate Bot commented Aug 12, 2024 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Aug 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

python-multipart vulnerable to Content-Type Header ReDoS

Details

Summary

Details

PoC

Impact

Original Report

Impact

Occurrences

Severity

References

Denial of service (DoS) via deformation multipart/form-data boundary

Details

Summary

Impact

Original Report

Severity

References

Python-Multipart has Arbitrary File Write via Non-Default Configuration

Details

Summary

Details

Affected Configuration

Impact

Mitigation

Severity

References

python-multipart affected by Denial of Service via large multipart preamble or epilogue data

Details

Summary

Details

Impact

Mitigation

Severity

References

python-multipart has Denial of Service via unbounded multipart part headers

Details

Summary

Impact

Details

Mitigation

Severity

References

python-multipart: Content-Disposition parameter smuggling via RFC 2231/5987 extended parameters

Details

Summary

Details

Impact

Mitigation

Severity

References

python-multipart: Semicolon treated as querystring field separator enables parameter smuggling

Details

Summary

Details

Impact

Mitigation

Severity

References

python-multipart: Quadratic-time querystring parsing with semicolon separators causes CPU denial of service

Details

Summary

Details

Impact

Mitigation

Severity

References

python-multipart: Negative Content-Length in parse_form buffers the entire body in memory

Details

Summary

Details

Impact

Mitigation

Severity

References

Release Notes

Configuration

renovate Bot commented Aug 12, 2024 •

edited

Loading

Denial of service (DoS) via deformation `multipart/form-data` boundary