GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

BREW-KIMI-CLI-CVE-2026-53540 (GHSA-V9PG-7XVM-68HF)

Vulnerability from osv_homebrew – Published: 2026-08-13 17:01 – Updated: 2026-09-17 20:03 – Source website
VLAI
Summary
python-multipart: Negative Content-Length in parse_form buffers the entire body in memory
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.


{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "python-multipart",
        "resource_purl": "pkg:pypi/python-multipart@0.0.32",
        "upstream_fixed_in": "0.0.31"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "kimi-cli",
        "purl": "pkg:brew/kimi-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.40"
            },
            {
              "fixed": "1.47.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/python-multipart@0.0.32",
        "name": "python-multipart",
        "resource": "python-multipart",
        "strategy": "registry",
        "subject_version": "0.0.32"
      }
    ]
  },
  "details": "### Summary\n\n`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.\n\n### Details\n\n`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.\n\n### Impact\n\nThis 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:\n\n* Starlette and FastAPI drive `MultipartParser` directly from the ASGI `receive()` stream and do not call `parse_form()`.\n* 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`.\n\nThe 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.\n\n### Mitigation\n\nUpgrade to version `0.0.31` or later, which rejects a negative `Content-Length` with a `ValueError` before reading the stream.",
  "id": "BREW-kimi-cli-CVE-2026-53540",
  "modified": "2026-09-17T20:03:17Z",
  "published": "2026-08-13T17:01:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Kludex/python-multipart/security/advisories/GHSA-v9pg-7xvm-68hf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Kludex/python-multipart"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "python-multipart: Negative Content-Length in parse_form buffers the entire body in memory",
  "upstream": [
    "GHSA-v9pg-7xvm-68hf",
    "CVE-2026-53540",
    "PYSEC-2026-3040"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…