Unbounded memory use on large request bodies
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 0.9.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The juniper_warp library, which provides GraphQL request handling for the Warp web framework, could read the entire body of a POST request into memory without any size limit. An unauthenticated client could send a very large request to exhaust a server's memory.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
The `make_graphql_filter()` and `make_graphql_filter_sync()` filters of `juniper_warp` read the whole body of a POST request into memory before they parsed the body. The filters had no limit on the size of the body. A client could thus send a large body and exhaust the memory of the server. The request needs no authentication. `juniper_warp` 0.9.1 reads at most 2 MiB of a request body by default. The filters respond with `413 Payload Too Large` to larger bodies. `make_graphql_filter_with_body_limit()` and `make_graphql_filter_sync_with_body_limit()` set another limit.
Timeline
- Advisory published
- Record last updated
- First seen by cve.now
Affected versions
- juniper_warpcrates.io
From 0.0.0-0 · fixed in 0.9.1