graphql-core のメモリリークによるサービス拒否（CVE-2026-119286）: 小さなクエリでメモリを使い切られる、3.3.1 で修正

Python 製の GraphQL ライブラリ graphql-core に、細工した小さなリクエストを送るだけでサーバーのメモリを使い切らせられる欠陥（CVE-2026-119286）が見つかりました。深刻度は High（CVSS 7.5）で、3.3.1 で修正されています。CISA の KEV には載っていません。EPSS は 10 月 30 日時点で 0.42% です。

何が起きるか

graphql-core は、受け取ったクエリの検証でエラーが 100 件（既定の max_errors）を超えると、検証を打ち切ります。このとき、毎回同じ 1 つのエラーオブジェクトを使い回して送出していました。Python は、同じ例外を再び送出するたびに、その呼び出しの履歴（トレースバック）を前のものに積み足します。そのため、打ち切られた検証 1 回ごとに、クエリ文書・検証の状態・エラー一式がメモリに残り続けます。

勧告によると、存在しない項目名を 101 個並べた小さなクエリで再現できます。CPython 3.12 では 1 回あたり約 124 KiB が残り、上限はありません。再起動か強制終了まで、メモリは増え続けます。

影響を受ける範囲

項目	内容
対象	graphql-core の 3.3.0a3 以上 3.3.1 未満
攻撃の条件	ネットワーク経由、認証不要、利用者の操作不要
影響	メモリの枯渇によるサービス拒否。情報の漏えいや改ざんはない
深刻度	GitHub の評価で High、CVSS v3.1 7.5（AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H）
弱点の種類	CWE-400、CWE-401
修正版	3.3.1（PyPI の最新版も 3.3.1）
KEV・EPSS	掲載なし・0.42%（10/30）

3.2 系は、打ち切りのたびに新しいエラーを作るため、対象外です。JavaScript 版の GraphQL.js も、エラーの履歴を作成時に 1 度だけ取るため、対象外とされています。

深さの制限や複雑さの解析を入れていても防げません。検証は実行より前に行われるためです。勧告は、数千件の小さなリクエストで、256 MB や 512 MB のコンテナの上限を超えて強制終了させられるとしています。

修正の内容と対応

3.3.1 では、打ち切りのたびに新しいエラーを作り、返す前にトレースバックと例外の連鎖を取り除きます。共有していたエラーオブジェクトは削除されました。

• graphql-core 3.3 系を使っている場合は、3.3.1 以降に更新してください。Strawberry など、graphql-core を内部で使うフレームワーク経由の利用も、依存のバージョンを確認してください。
• すぐに更新できない場合、勧告は回避策を示しています。検証関数を包み、呼び出しのたびに共有エラーの __traceback__ を None に戻します。
• GraphQL の公開エンドポイントで、ワーカーのメモリが時間とともに増え続けていないか、強制終了が繰り返されていないかを確認してください。
• リバースプロキシ側で、1 リクエストあたりのサイズや頻度を制限しておくと、被害を抑えやすくなります。

確認できていない点

• 勧告に、実際の攻撃が確認された記載はありません。KEV にも載っていません。
• 124 KiB という数値は、勧告が CPython 3.12 で測ったものです。実際の増え方は、クエリの内容と環境で変わります。