GitHub、GraphQL-coreの停止につながる欠陥2件を掲載、更新確認を

GitHubは、GraphQL-coreでサービス停止につながる脆弱性2件を掲載しています。メモリーを使い切らせる問題と、検証処理でCPUを占有する問題で、いずれも3.2.12と3.3.0rc1で修正されました。認証なしで攻撃できるため、利用企業は更新状況と、リクエスト本文を制限する位置の確認が必要です。

既存の制限をすり抜け、メモリーとCPUを消費

CVE-2026-75508は、文書を解析するパーサーの問題です。トークンという文書の構成要素の数を制限するmax_tokensに、コメントが数えられていませんでした。一方で、コメントもTokenオブジェクトとして確保され、文書が存続する間はメモリーに残ります。

勧告では、max_tokens=5でも38.1 MBの入力でプロセスの使用メモリーが92 MB増加しました。同時にリクエストを受けると、コンテナのメモリー上限を超えて強制終了する恐れがあります。解析後に働く深さ制限や複雑度分析では防げません。この欠陥によるデータの漏えいや改変は伴わないとしています。

もう1件のCVE-2026-75507は、OverlappingFieldsCanBeMergedという検証ルールの比較処理が原因です。インラインフラグメントを繰り返すクエリで処理量が膨らみます。勧告では、364 KBの文書の検証に319秒かかり、データ取得などを担うリゾルバーの実行前にCPUを占有しました。

このルールは標準で有効です。少数の同時リクエストでも複数の処理担当を使い切る恐れがあります。攻撃用文書は数KBに圧縮できるため、圧縮状態だけを見る本文制限や、Webアプリへの攻撃を防ぐWAFをすり抜け得る点にも注意が必要です。

修正版はコメント集計と比較回数の制限を変更

3.2.12と3.3.0rc1では、末尾を含むコメントもmax_tokensに数えます。解析済み文書のtoken_count属性にもコメントが含まれます。そのため、コメントの多い文書は、更新前と同じ設定でも拒否される場合があります。

検証処理には、文書ごとに既定で250,000回の比較上限を設けました。上限に達すると検証エラーで中止します。上限はMAX_FIELD_COMPARISONS定数で変更できますが、勧告は、修正後も本文サイズ制限を併用するよう勧めています。比較回数だけでは、リクエスト全体の負荷を制限できないためです。

資料では両勧告の公開日は確認できません。日本での提供は発表には書かれていません。

影響する会社・しない会社

• 影響する: GraphQL-coreを利用し、コメントを含む入力をmax_tokensだけで制限している会社です。解析後の深さ制限や複雑度分析だけでは、今回のメモリー枯渇を防げません。
• 影響する: 標準設定のGraphQL-coreサーバーを運用する会社です。CPU占有の原因となる検証ルールが標準で有効になっています。
• 影響しない: GraphQL-coreを使っていないシステムは、今回の2件の対象ではありません。利用の有無が分からない場合は、開発担当や委託先への確認が必要です。
• 影響しない: 3.2.12または3.3.0rc1で修正された2件については、これらの修正版への更新で対策できます。ただし、更新後もリクエスト全体の負荷対策は別に必要です。

情シスが今日やること

1. 開発担当・委託先に利用状況を照会します。 アプリの依存パッケージ一覧と稼働環境で、GraphQL-coreの有無、版、担当者を確認してもらいます。共通の管理画面や操作手順は発表には書かれていません。未確認のシステムは、回答期限を社内で決めて一覧に残します。
2. 更新前に、正規の文書が通るか確認します。 修正版への更新計画を立て、コメントの多い文書を現在のmax_tokens設定で試します。開発担当には、token_countの集計も変わることを伝え、更新前に影響を確認してもらいます。
3. 更新を待つ間は、解凍後の本文制限を確認します。 アプリ担当に、parse()とvalidate()へ渡す前にサイズ制限があるか確認してもらいます。圧縮された通信量だけを制限していないか、処理の順序まで点検します。安全な上限値は発表には書かれていません。
4. 回避策と更新完了条件を共有します。 検証ルールを外す方法は、仕様上必要な確認を失うため安全な回避策ではありません。運用担当と開発担当で、修正版の適用、正規の文書の検証、本文サイズ制限の確認を完了条件として合意します。