Skip to content

← Actionable
High, CVSS 8.2amended

Litestar allows unbounded resource consumption (DoS vulnerability)

CVE-2024-52581GHSA-gjcc-jvgw-wvwj

What to do

Partial vendor fix. Follow the primary source's mitigation guidance and check back for a fix.

This page has no inventory attached, so it cannot say whether you are affected. A vendor fix is not proof that your deployment is fixed.

Affected packages

  • PyPI litestar

    Affected
    <= 2.12.1
    Fixed in
    2.13.0
  • PyPI starlite

    Affected
    <= 1.51.16
    Fixed in
    no fixed version recorded

Sources

Severity and exploitation
Exploitation
No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.
CVSS 4.0
8.2 · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L · score source
EPSS
  • CVE-2024-52581: 0.79% estimated exploitation activity in the next 30 days; percentile 56.44 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.
Source description

As published by the source; long descriptions are shortened.

Summary Litestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests. Details The Request methods to parse json, msgpack or form-data all read the entire request stream into memory via await self.body() without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen. For most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via multipart/form-data, a simple size limit would not be practical. The multipart…

Dates and revisions
Published by the source
Last modified by the source
Source last checked
  1. Revision 3 · amended ·

    Amended from ghsa record GHSA-gjcc-jvgw-wvwj

  2. Revision 2 · amended ·

    Reviewed OSV alias/range/CVSS4 correction; package source scopes and original publication preserved. No customer finding resolved.

  3. Revision 1 · created ·

    Published from osv record GHSA-gjcc-jvgw-wvwj

Agent brief

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2024-52581

Advisory: Litestar allows unbounded resource consumption (DoS vulnerability)
IDs: CVE-2024-52581, GHSA-gjcc-jvgw-wvwj
Record: https://patchnext.com/advisories/cve-2024-52581 (revision 3, source checked 26 Oct 2026, 13:30 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: High (CVSS 8.2)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Partial vendor fix; fixed versions by package: litestar 2.13.0. A vendor fix does not mean a deployment is fixed.

## Affected components
- PyPI litestar: affected <= 2.12.1; fixed in 2.13.0
- PyPI starlite: affected <= 1.51.16

## Suggested inspection (read-only)
- `python -m pip show litestar`: prints the installed version. Run with the environment that serves production active.
- `python -m pip show starlite`: prints the installed version. Run with the environment that serves production active.

## Supported action
No complete vendor fix is recorded. Follow the primary source's mitigation guidance and check this record again before closing anything.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on litestar, starlite.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/GHSA-gjcc-jvgw-wvwj (OSV record GHSA-gjcc-jvgw-wvwj lists affected ranges: PyPI litestar >=0 =0 <=1.51.16)
- Verified: https://github.com/advisories/GHSA-gjcc-jvgw-wvwj (GitHub-reviewed advisory GHSA-gjcc-jvgw-wvwj lists affected ranges: PyPI litestar >=0 =0 <=1.51.16)

Commands are suggestions: review each one before running it.

Loading voting…