Zero Radar
← feed
HighVulnerabilityCVE-2026-119286updated 30 Oct 2026, 22:59 UTC

graphql-core (Python) leaks memory when a document has too many validation errors

A short, specially crafted GraphQL request can make the server keep growing its memory use, and each repeated request adds more. A busy server can eventually run out of memory and crash, but no data is stolen or changed.

Fixed in 3.3.1 · out Official, 2 sources
SeverityHighCVSS 7.5 of 10
Being exploited?UnclearNo reports either way yet
Fix available?Yes3.3.1 · since 30 Oct 2026
How sure is this?Official, 2 sourcesBacked by an official source

How the attack works simplified

  1. 1AttackerSends small unauthenticated GraphQL request
  2. 2Validation runsDocument has more than 100 errors
  3. 3Shared error reusedTraceback keeps growing on each call
  4. 4Memory growsDocuments and contexts never released
  5. ResultWorker runs out of memory and crashes

What happened

In graphql-core 3.3.0a3 through 3.3.1, validate() re-raises a shared module-level ValidationAbortedError when a document exceeds max_errors (100 by default). Python keeps appending traceback frames to that same object, so the documents, validation contexts and error sets of every aborted validation stay in memory for the life of the process.

Why it is dangerous: An unauthenticated client can repeatedly send a small document with more than 100 validation errors, causing unbounded memory growth until the worker is killed. Services running graphql-core on Python that accept requests from the internet are at risk of denial of service.

Are you affected?

You are affected if you run graphql-core 3.3.0a3 up to (but not including) 3.3.1 in a Python service that validates GraphQL documents from clients, including unauthenticated ones.

Package / productAffected versionsFixed in
graphql-core · pip>= 3.3.0a3, < 3.3.13.3.1

What to do

  1. Upgrade graphql-core to version 3.3.1 or later
  2. If you cannot upgrade yet, wrap validate() so it clears the shared error's __traceback__ after each call (workaround in the advisory)
  3. Monitor worker memory use and restart workers that grow steadily

Timeline

  1. 29 Oct 2026, 22:17 UTC
    Publicly disclosed
  2. 29 Oct 2026, 22:17 UTC
    Reported by NVD · NVD
  3. 29 Oct 2026, 22:17 UTC
    Picked up by Zero Radar
  4. 30 Oct 2026, 22:59 UTC
    GitHub Advisory reported on it · GitHub Advisory
  5. 30 Oct 2026, 22:59 UTC
    Fixed version published: graphql-core 3.3.1 · GitHub Advisory

Sources 2 reports, oldest first

Official vendor, government CERT or advisory database

Technical details

ID
CVE-2026-119286 · GHSA-mpqx-q82w-9x46
CVSS
7.5 / 10
Disclosed
29 Oct 2026, 22:17 UTC
On Zero Radar
29 Oct 2026, 22:17 UTC (0 min after disclosure)
Last change
30 Oct 2026, 22:59 UTC

The plain-language parts and the attack diagram were written by an AI model (anthropic/claude-haiku-5.5) from the sources above. Facts like versions, exploitation and dates come from the sources themselves. How Zero Radar works

graphql-core (Python) leaks memory when a document has too many validation errors · Zero Radar