LangChain Coreのシリアル化インジェクション（CVE-2025-68664）が秘密漏えいとRCEを誘発——AIアプリ基盤へのチェーンリスクが顕在化です

今日の深掘りポイント

• 典型的な「危険なデシリアライゼーション」の再来がLLMフレームワーク層で発生し、データプレーンからコントロールプレーンへ越境する設計リスクが露呈しています。
• ユーザー制御データに含まれる特定のキーをトリガにLangChainオブジェクトが不正生成され、環境変数の秘密窃取や条件次第で任意コード実行に至る可能性が指摘されています。
• パッチは提供済みで、更新と同時に秘密のローテーション、入力バリデーション強化、許可クラスの明示的な制限（アロウリスト）設定が急務です。
• 生成AI特有の「モデル出力をそのまま構造化データとして扱う」実装習慣が攻撃面を広げており、チャットUI・RAG・エージェント・ツール実行系すべてで影響が連鎖し得ます。
• メトリクス全体像からは緊急性と実行可能性が高く、かつ信頼度の高い警戒情報と読み取れます。運用現場では72時間以内に是正・検知・隔離の3本柱で対応を完了させるべきです。

はじめに

LangChain Coreにシリアル化インジェクションの重大な脆弱性（CVE-2025-68664）が報告され、CVSS 9.3と評価されています。公開情報によれば、ユーザーが制御するデータに含まれる特定のキーが、LangChainの内部オブジェクト生成を誘発し、環境変数からの秘密抽出や任意コード実行につながる恐れがあるとのことです。ベンダは既にパッチを提供しており、アップデートが推奨されています。また、影響バージョンや脆弱な関数（dumps/dumpd）に関する説明、デフォルト動作の制限導入や許可クラスの明示化などの対策が報じられています。これらの点は、LLM基盤が重要インフラや企業の運用に深く組み込まれる現在、セキュリティ・アーキテクチャの前提を問い直すシグナルと捉えるべきです。

参考として公表報道は以下を参照ください。

• The Hacker News: Critical LangChain Core Vulnerability...

深掘り詳細

事実整理（現時点の公開情報）

• 脆弱性: LangChain Coreにおけるシリアル化インジェクション（CVE-2025-68664）、CVSS 9.3です。
• 作用機序: ユーザー制御データに含まれる特定のキーが、LangChain内部のオブジェクト生成を引き起こす設計となっており、不正オブジェクトの生成が可能になるとの報告です。結果として、環境変数からの秘密抽出や、実装や許可クラス構成によっては任意コード実行の可能性が生じます。
• 影響範囲: 公開情報では、LangChain Core 1.0.0以上で1.2.5未満、または0.3.81未満が影響を受けるとされています（報道ベースの情報です）。
• 実装箇所の指摘: dumps()およびdumpd()関数周辺で、ユーザー制御データ中の特定キーの取り扱いが不適切であったと報じられています。
• ベンダ対応: パッチにより、制限付きの新デフォルトを導入し、許可するクラスの明示的指定（アロウリスト）を可能にした旨が伝えられています。アップデート適用が推奨されています。

上記は公開報道に基づく整理であり、詳細な技術仕様やコミット差分などの一次情報は、読者環境での検証と合わせて最新のベンダ告知を確認することを推奨します。

編集部インサイト（なぜ深刻か、何が特有か）

• 古典的な問題がLLM基盤に再出現です: これはAI特有の“プロンプトインジェクション”とは性格を異にし、クラシカルな「危険なデシリアライゼーション」の問題がLLMアプリのミドルウェア層に現れた事例です。すなわち、入力データ（データプレーン）が、内部オブジェクト生成（コントロールプレーン）に昇格する動線を持ってしまった設計上の問題です。
• モデル出力も「外部入力」になり得ます: LLMアプリは、ユーザー入力だけでなくモデル出力（ツール引数、エージェント状態、メモリスナップショット）を再シリアル化・再解釈する実装が一般化しています。したがって、攻撃トリガは人手入力に限らず、モデル出力を経由した2段階注入も起こり得ます。RAGの取り込み文書、ウェブスクレイピング結果、ベクタDBからの再構成データなど、多様な入口が「ユーザー制御データ」相当になり得る点がAI特有の広がりです。
• 秘密の近接性が高いのがLLMアプリの特徴です: 多数のAIアプリはOpenAI/Azure/GCP等のAPIキーやストレージ資格情報を環境変数で保持します。アプリプロセスの権限でこれらが取得可能である以上、オブジェクト生成を悪用した秘密抽出は攻撃の効果が高いです。RCEの可否は許可クラス構成やサンドボックス有無に依存しますが、少なくとも秘密窃取の実害は現実的に想定すべきです。
• ガードレールは「後段」ではなく「手前」に必要です: 多くの組織は出力フィルタやプロンプトサニタイズを強化してきましたが、今回の論点はシリアライザ／デシリアライザの境界そのものです。許可クラスのアロウリストと強制的な型バリデーション（スキーマ）を入口段階で実施しない限り、モデルやWAFのガードレールだけでは遮れません。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った仮説ベースのシナリオです。実環境での実現性は各組織の実装や権限設計に依存します（仮説であることに留意ください）。

• シナリオ1：公開エンドポイントからの直撃

  • 概要: チャットやJSON APIが受け取ったペイロードに特定キーを含め、アプリが内部でdump/dumpdや同等の復元処理を行うことで不正オブジェクト生成を誘発します。
  • ATT&CK:
    • 初期侵入: Exploit Public-Facing Application（T1190）です。
    • 実行: Command and Scripting Interpreter（T1059）に相当するオブジェクトが許可されていればRCEに発展します（仮説）。
    • 資格情報アクセス: Unsecured Credentials: Credentials in Environment（T1552.008）で環境変数からAPIキー等を窃取します。
    • 情報収集・送出: System Information Discovery（T1082）、Exfiltration Over C2 Channel（T1041）等に接続します。

• シナリオ2：モデル出力を経由した二段階注入

  • 概要: 悪意ある文書やウェブページをRAGで取り込み→モデルがその構造を反映した出力を生成→アプリがその出力を再デシリアライズして内部オブジェクト化、という連鎖です。
  • ATT&CK:
    • 初期侵入: User Execution/Content（T1204相当の流れ）に近い形で外部コンテンツが導入されます（仮説）。
    • 継続工程はシナリオ1と同様です。

• シナリオ3：ツール実行系の連鎖

  • 概要: エージェントのツール呼び出し引数やプラグイン設定がシリアライズされた形で保存／再構築される設計の場合、攻撃者が引数内に特定キーを混入させて許可クラスを介した攻撃へ展開します。
  • ATT&CK:
    • 実行: T1059（ツールやREPL相当が許可されている場合）。
    • 防御回避: Modify Authentication Process/Bypass（該当する場合、設計依存）です（仮説）。

• シナリオ4：マルチテナントSaaS基盤での横展開

  • 概要: 1テナントの攻撃成功により共有実行基盤のメタデータやサービスアカウント資格情報に触れられると、多テナント波及の懸念が生じます。
  • ATT&CK:
    • 資格情報アクセス: T1552.008。
    • 横展開: Valid Accounts（T1078）やCloud Credentials Abuses等に接続し得ます（仮説）。

ビジネス影響としては、APIキー・署名鍵・DB接続文字列の露見、顧客データへの二次被害、規制順守違反（個人情報／秘匿情報保護）、モデルやベクトルDBの汚染による長期的な信頼性毀損が想定されます。重大度は高く、修復コストは鍵ローテーションの範囲を超え、設計見直し・検証自動化・観測性強化に及ぶと見ます。

セキュリティ担当者のアクション

優先順位と時間軸で整理します。

• 0〜24時間（緊急対応）

  • 直ちにベンダのパッチを適用し、LangChain Coreを最新安定版へ更新します（影響範囲は公開情報ベース。組織内SBOM/資産台帳で該当システムを特定します）。
  • 公開エンドポイントでユーザー制御データをシリアライズ／デシリアライズするパスを一時的に無効化または隔離します。必要に応じて該当機能を機能フラグで停止します。
  • 監査ログの集約とアラートを有効化し、特定キーを含む異常な入力パターン、失敗したオブジェクト生成例外、環境変数参照の急増などの兆候を検出します（検出ロジックは実装依存のため仮説ベースですが、異常なキー名やオブジェクト型の急増が手掛かりになります）。

• 24〜72時間（封じ込めと被害最小化）

  • 秘密情報のローテーションを実施します。対象はAI APIキー、ストレージ/DB資格情報、外部SaaS統合のアクセストークン、署名鍵など、プロセス環境に露出するものを最優先にします。
  • 実行基盤のサンドボックス化を強化します。コンテナでのseccomp/AppArmor、最少権限のサービスアカウント、アウトバウンド通信のドメイン/ポート制限（egress制御）を適用します。RCEが成立しても外部持ち出しや横展開を困難にします。
  • シリアライズ境界のアロウリストを強制します。ベンダが提供する「許可クラスのみ復元」設定を有効化し、アプリ側でも受け入れスキーマをpydantic等で厳格に定義します。自由形式のdict受け渡しを廃止します。
  • モデル出力の再解釈を安全化します。LLM出力は必ず厳格スキーマで検証し、未知キーは拒否、危険キーは予約語として拒絶します。RAG/スクレイピング経路も含め、外部コンテンツ由来の構造化データは一律で不信扱いにします。

• 1〜2週間（恒久対策）

  • テストと検証の自動化です。セキュリティ単体テストに「特定キー混入」のファジングケースを組み込み、シリアライザ/デシリアライザの安全性を継続検証します。
  • 観測性（Observability）の強化です。オブジェクト復元失敗、危険キー拒否、環境変数アクセスの監査イベントをメトリクス化し、しきい値を定義してアラートします。
  • アーキテクチャの再設計です。秘密は環境変数からの直接参照を避け、短寿命トークン（STS）や専用シークレットマネージャ経由に切り替えます。モデル実行ワーカーとAPIフロントをプロセス/名前空間で分離し、爆発半径を限定します。
  • サプライチェーン管理です。LLMフレームワークや周辺ツール（エージェント実行、ツールプラグイン、コールバック）を含めたSBOMを整備し、脆弱性フィードと連携して自動通知・自動パッチの流れを作ります。

• 現場への示唆（メトリクスの読み解きに基づく所感）

  • 緊急度と実行可能性が高い一方で、根治には設計面の手当が要ります。単に「アップデートした」で終わらせず、アロウリストとスキーマ厳格化、eBPF/WAF等の境界検査、短寿命シークレット化まで踏み込むべきです。
  • 類似実装の横展開に注意です。同様のシリアライゼーション設計を持つ他フレームワーク（LLMに限らず）でも再発し得ます。パターンとしての対策（入力不信・型厳格・最少権限・出力制御）を標準化することが再発防止の近道です。

参考情報

• The Hacker News: Critical LangChain Core Vulnerability Allows Secret Theft and RCE via Serialization Injection (CVE-2025-68664)

以上、現時点の公開情報に基づく分析と提言でした。追加の一次情報（ベンダのアドバイザリ、リリースノート、CVE詳細）が公開され次第、設計と検知の両面でアップデートを継続することを強く推奨します。