GraphQL-core: Denial of service via memory leak in aborted validations
- 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 3.3.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
GraphQL-core, a Python port of the GraphQL.js reference implementation, is affected in its 3.3 pre-release and early 3.3 releases. An unauthenticated remote client can repeatedly send small GraphQL documents that trigger many validation errors, causing memory to grow without limit until the server process runs out of memory and becomes unavailable.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
GraphQL-core is a Python port of the GraphQL.js reference implementation. From 3.3.0a3 until 3.3.1, validate() reuses a module-level ValidationAbortedError when a document exceeds max_errors. Python appends frames to the reused exception's traceback on every raise, retaining each document, validation context, and error set for the process lifetime. An unauthenticated client can repeatedly submit a small document with more than 100 validation errors to cause unbounded memory growth before query execution, eventually exhausting worker memory without disclosing or modifying data. This issue is fixed in version 3.3.1.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- graphql-python graphql-core
From 3.3.0a3 · fixed in 3.3.1