LangGraph JSで認証情報の分離に関する不具合が公表、共有ヘッダーオブジェクトにより異なるクライアント間でAPIキーが混在する可能性

LangGraph JSのメンテナーは10月7日、セキュリティアドバイザリー GHSA-432w-3h3v-2pv4 を公開した。アプリケーションが同じ defaultHeaders オブジェクトを複数のSDKクライアントに渡すと、後から作成されたクライアントが、先に作成されたクライアントで使われるAPIキーを上書きする可能性がある。アドバイザリーではリスクを Low と評価し、CVSS 4.0のスコアを2.1として、修正版を示している。セキュリティアドバイザリー

この不具合は、JavaScriptのオブジェクト参照の扱いに起因する。公開パッケージの BaseClient コンストラクターは config.defaultHeaders をそのまま保持し、その中の x-api-key にキーを書き込む。そのため、各クライアントで個別に apiKey を設定していても、同じ可変ヘッダーを参照している場合がある。2回目の初期化によって、1つ目のクライアントが以後送信する認証情報が変わる可能性がある。このロジックは、公開済みのバージョン1.5.2パッケージのソースマップで確認できる。パッケージコード

誤解されやすいもう1つの点は apiKey: null だ。パッケージコードによると、この設定は環境変数の読み込みをスキップするが、コンストラクターは共有ヘッダーにすでに設定されているキーを削除しない。つまり、コードから推測できるのは、自動読み込みを無効にしても最終的なリクエストに認証情報が含まれないとは限らないということだ。ヘッダーオブジェクトが別のクライアントによって変更されたことがないかも確認する必要がある。パッケージコード

エージェントサービスとの統合では、ヘッダーと認証情報はいずれも実際のデプロイ時に使われるインターフェースの一部だ。LangChainのFleetドキュメントでは、Client で apiUrl、apiKey、defaultHeaders を設定し、runs.wait を通じてエージェントを呼び出す方法を紹介している。こうした設定を共通テンプレートにまとめているエンジニアリングチームは、オブジェクト参照を再利用していないか特に確認すべきだ。これはインターフェースと不具合の仕組みに基づく確認事項であり、ドキュメントのサンプル自体に脆弱性があるという意味ではない。公式統合ドキュメント

アドバイザリーは、SDKを1.12.3以降に、@langchain/langgraph を1.4.21以降にアップグレードするよう推奨している。修正では初期化時にヘッダーを複製する。デプロイ時の確認では、共有された入力オブジェクトが変更されていないことと、各クライアントがそれぞれのキーを送信することを検証すべきだ。メンテナーはまた、上記の構成がなければ外部の攻撃者が直接この問題を引き起こすことはできず、LangGraph Platformはこの不具合の影響を受けないと明記している。修正と影響範囲