LangChainとLangGraphに3件の脆弱性、ファイル・秘密情報・会話履歴が漏洩

LLMアプリケーション開発のデファクトフレームワークであるLangChainとLangGraphに、3件のセキュリティ脆弱性が公開された。CVSS 9.3のデシリアライゼーション脆弱性、CVSS 7.3のSQLインジェクション、CVSS 7.5のパストラバーサル（ディレクトリトラバーサルとも呼ぶ。ファイルパスの検証不備を突いて本来アクセスできない任意のファイルを読み取る攻撃）。3件がそれぞれ環境変数・会話履歴・ファイルシステムという異なるデータクラスを標的にしている点が厄介だ。

セキュリティ研究者のVladimir Tokarev氏（Cyera社）は「各脆弱性が異なるクラスのエンタープライズデータを露出させる」と述べている。

LangChainエコシステムの脆弱性としては、先日のLangflowのCVE-2026-33017（CVSS 9.3、未認証RCE）に続く報告となる。Langflowとは異なり今回の3件は認証済み環境でも悪用可能で、しかもプロンプトインジェクション経由でトリガーできる。

3件の脆弱性の概要

CVE ID	対象パッケージ	CVSS	脆弱性の種類	漏洩データ	修正バージョン
CVE-2025-68664	langchain-core	9.3	デシリアライゼーション	環境変数・APIキー	0.3.81 / 1.2.5
CVE-2025-67644	langgraph-checkpoint-sqlite	7.3	SQLインジェクション	会話履歴・チェックポイント	3.0.1
CVE-2026-34070	langchain-core	7.5	パストラバーサル	任意ファイル	1.2.22

langchain-coreのダウンロード数は月間約9,800万回（2025年12月時点）。影響範囲は広い。

CVE-2025-68664 “LangGrinch” デシリアライゼーションによる秘密情報窃取

最も深刻な脆弱性。Cyera社のYarden Porat氏が発見し「LangGrinch」のコードネームを付けた。LangChainに対する最大額の$4,000の報奨金（バウンティ）が支払われている。

LangChainのシリアライゼーション構造

LangChainは内部で独自のシリアライゼーション形式を使う。辞書（dict）に lc というキーが含まれていると、デシリアライザ（loads/load関数）はそれをLangChainの内部オブジェクトとして解釈し、対応するクラスをインスタンス化する。

問題は dumps() と dumpd() にあった。ユーザーが制御できる辞書に lc キーが含まれていても、エスケープせずそのまま出力していた。結果として、攻撃者が仕込んだデータが正規のLangChainオブジェクトとしてデシリアライズされる。

攻撃経路

12の脆弱なフローが特定されている。

astream_events(version="v1")
Runnable.astream_log()
dumps() / dumpd() → load() / loads()
メッセージ履歴・メモリのシリアライゼーション
キャッシュ操作
イベントストリーミングとロギング

現実的な攻撃シナリオでは、LLMのレスポンスに含まれる additional_kwargs や response_metadata フィールドが悪用される。これらはプロンプトインジェクション経由で制御可能だ。攻撃者がLLMに出力させた lc 構造体が、フレームワークのストリーミングや履歴保存の過程でシリアライズ → デシリアライズされ、オブジェクトインスタンス化が発生する。

AIエージェントに対するプロンプトインジェクション防御が話題になっているが、今回の脆弱性はまさにプロンプトインジェクションがフレームワーク層の脆弱性をトリガーする実例だ。

秘密情報の窃取メカニズム

パッチ適用前の loads() は secrets_from_env がデフォルトで True に設定されていた。このオプションが有効な場合、デシリアライズ時に「secret」型オブジェクトが環境変数から値を解決する。

攻撃の流れはこうなる。

flowchart TD
    A[攻撃者が細工したプロンプトを送信] --> B[LLMレスポンスに<br/>lc構造体が混入]
    B --> C[ストリーミング・履歴保存で<br/>dumps実行]
    C --> D[lcキーがエスケープされず<br/>シリアライズ]
    D --> E[loads実行時に<br/>LangChainオブジェクトと誤認]
    E --> F[secrets_from_envがTrue<br/>環境変数から秘密情報を解決]
    F --> G[インスタンス化時に<br/>HTTPリクエスト発生]
    G --> H[環境変数がHTTPヘッダに<br/>含まれ攻撃者サーバーへ送信]

具体的には、許可リスト内の ChatBedrockConverse クラスが悪用される。このクラスはコンストラクタで endpoint_url パラメータを受け取り、初期化時にGETリクエストを発行する。攻撃者は endpoint_url を自分のサーバーに向け、環境変数から解決された秘密情報をHTTPヘッダに注入できる。

加えて、許可リスト内の PromptTemplate はJinja2テンプレートレンダリングをサポートしており、デシリアライズ後のオブジェクトに対してレンダリングが実行されれば任意のPythonコード実行の可能性もある。

修正内容

lc キーを含むユーザー制御辞書のエスケープ処理を追加
secrets_from_env のデフォルトを True から False に変更
デシリアライゼーションパスのバリデーション強化

CVE-2025-67644 SQLインジェクションによる会話履歴漏洩

LangGraphのSQLiteチェックポイント実装に存在するSQLインジェクション脆弱性。LangGraphはLangChain上に構築されたステートフルなマルチアクターアプリケーションフレームワークで、会話の状態をチェックポイントとしてSQLiteに保存する機能を持つ。

脆弱なコード

_metadata_predicate() 関数が、メタデータフィルタのキーをf-stringで直接SQLクエリに埋め込んでいた。

for query_key, query_value in metadata_filter.items():
    operator, param_value = _where_value(query_value)
    predicates.append(
        f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"
    )

フィルタの値はパラメータ化クエリで安全に処理されていたが、キーはバリデーションなしに直接文字列結合されていた。SQLインジェクション対策としてプリペアドステートメントを使いながら、キー側が素通りというのはありがちな見落としだ。

攻撃例

# 攻撃者が制御するフィルタ
malicious_filter = {"x') OR '1'='1": "dummy"}

# 生成されるSQL
# WHERE json_extract(CAST(metadata AS TEXT), '$.x') OR '1'='1') = ?

OR '1'='1' でWHERE句が常に真になり、全チェックポイントレコードが返却される。会話履歴、スレッドID、メタデータが丸ごと漏洩する。カスタムサーバーデプロイメントでチェックポイント検索エンドポイントが外部に公開されている場合、リスクが高い。LangSmith経由のデプロイメントはカスタムチェックポインタを構成できないため影響を受けない。

修正内容

パッチでは _validate_filter_key 関数が追加され、正規表現 ^[a-zA-Z0-9_.-]+$ でフィルタキーの文字種を制限している。

CVE-2026-34070 パストラバーサルによる任意ファイル読み取り

langchain_core/prompts/loading.py のプロンプト読み込みAPIに存在するパストラバーサル脆弱性。プロンプトテンプレートのファイルパス指定にバリデーションがなく、../../etc/passwd のような相対パスを渡すとサーバー上の任意ファイルを読み取れる。

Dockerコンテナの設定ファイル、.env ファイル、SSHキーなどが攻撃対象になる。CVSS 7.5はネットワーク経由・認証不要・機密性への影響が高い評価。

修正済みバージョンはlangchain-core 1.2.22以降。

3つの脆弱性を組み合わせた攻撃シナリオ

3件の脆弱性はそれぞれ独立しているが、同一のLangChainデプロイメント上で組み合わせるとダメージが増幅する。

flowchart TD
    A[CVE-2026-34070<br/>パストラバーサル] --> B[.envファイルや設定ファイルを読み取り]
    B --> C[DB接続情報・内部パスを取得]
    C --> D[CVE-2025-67644<br/>SQLインジェクション]
    D --> E[チェックポイントDB全件ダンプ<br/>会話履歴・メタデータ取得]
    A --> F[Dockerfileやデプロイ設定を読み取り]
    F --> G[環境変数名を特定]
    G --> H[CVE-2025-68664<br/>デシリアライゼーション]
    H --> I[環境変数からAPIキー窃取<br/>外部送信]

パストラバーサルで設定ファイルを読み取って環境変数名を特定し、デシリアライゼーション脆弱性でその環境変数の値を外部に送信する。並行してSQLインジェクションで会話履歴をダンプすれば、ファイルシステム・秘密情報・会話データの三つを同時に窃取できる。

AIフレームワークに固有の攻撃面

今回の脆弱性群は従来のWebアプリケーション脆弱性（SQLi、パストラバーサル、デシリアライゼーション）と分類上は同じだが、AIフレームワーク特有の文脈がある。

従来のWebアプリなら、SQLインジェクションの入口はフォーム入力やURLパラメータだった。LangChainの場合、LLMのレスポンスそのものが入力ベクターになる。プロンプトインジェクションでLLMの出力を制御し、その出力がフレームワーク内部のシリアライゼーション・DB操作・ファイル読み込みを経由して脆弱性をトリガーする。ユーザーの直接入力ではなくLLMの出力が攻撃ペイロード（攻撃コード本体）の運び屋になるという構造は、従来のWAF（Web Application Firewall）では検知が難しい。

AIエージェントフレームワークの脆弱性が相次いで報告されている状況と合わせて、LLMアプリケーション基盤のセキュリティ監査は急務になっている。

対応

影響を受けるパッケージと修正バージョンを再掲する。

パッケージ	修正バージョン
langchain-core	0.3.81 / 1.2.5（CVE-2025-68664）
langchain-core	1.2.22（CVE-2026-34070）
langgraph-checkpoint-sqlite	3.0.1（CVE-2025-67644）

langchain-coreは1.2.22にすれば2件とも修正される。pip show langchain-core langgraph-checkpoint-sqlite でバージョンを確認し、該当する場合は即座にアップデートすべきだ。加えて、LLMのレスポンスフィールド（additional_kwargs、response_metadata、ツール実行結果）は信頼できないデータとして扱い、デシリアライゼーション前のバリデーションを入れておくのが防衛的な対策になる。