Live › vulnerability › CVE-2026-119286
graphql-core, a Python GraphQL library, keeps a shared validation error object that grows its traceback on every oversized document, so memory is never released. An unauthenticated client sending small invalid queries can drive memory use up until the worker process is exhausted, causing denial of service.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 22:27 UTC. All times on this page are UTC.
Python services that use graphql-core 3.3.0a3 through 3.3.0 patch releases, and that accept GraphQL queries from clients the team does not control, are exposed. Services pinned to earlier releases or that never validate untrusted documents are less exposed. Services limited to trusted internal callers are lower risk.
No product ranges from the sources yet.
pip show graphql-core and look for versions from 3.3.0a3 up to but not including 3.3.1.poetry.lock, requirements.txt, uv.lock) for graphql-core pinned to those versions.graphql-core 3.3.1Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-119286")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.