2025/12/26 3:06

LangChain の深刻な脆弱性 – CVE‑2025‑68664

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

Summary

LangChainは、

langchain-core

のシリアライズ関数（

dumps()

dumpd()

）に欠陥があることを示す重要なアドバイザリ（CVE‑2025‑68664 / GHSA‑c67j‑w6g6‑q2cm）を公開しました。信頼できない辞書で予約キー “lc” を含む場合、適切にエスケープされずにシリアライズされるため、デシリアライズ時に任意のオブジェクト生成が可能になります。これにより、環境変数から秘密情報を抽出（デフォルトで

secrets_from_env=True

は 2025年12月5日まで）、不安全なコンストラクタ副作用、および最終的には任意コード実行が発生する恐れがあります。

脆弱性は CWE‑502 と分類され、CVSS スコアは 9.3（クリティカル）です。すべてのコアリリース 1.2.5 および 0.3.81 より前が影響を受け、パッチは 2025年12月24日 に公開されました。一般的な脆弱フローにはイベントストリーミング、ロギング、メッセージ履歴/メモリ、キャッシュ、および

RunnableWithMessageHistory

や

InMemoryVectorStore.load()

などの内部パスが含まれます。最も現実的な攻撃ベクトルは、ストリーミング操作中にプロンプトインジェクションを介して LLM 出力フィールド（

additional_kwargs

、

response_metadata

）を操作し、シリアライズされたペイロードを再びオブジェクトとしてデシリアライズすることです。これにより、環境変数からヘッダーが埋め込まれたネットワーク呼び出し（例：

ChatBedrockConverse

）がトリガーされる可能性があります。

影響を受けるホワイトリストクラスは

langchain_core

、

langchain_openai

、

langchain_aws

、

langchain_anthropic

などにわたります。LangChainJS も同様のメカニズムを持つ関連アドバイザリ（GHSA‑r399‑636x‑v7f6 / CVE‑2025‑68665）があります。

Cyata は発見に対して $4,000 USD の報奨金を受け取りました—これは LangChain の報奨金プログラムで最高額です。開示タイムラインは以下の通りです：報告提出 2025年12月4日、確認 2025年12月5日、アドバイザリと CVE 公開 2025年12月24日。

世界中で約 8億4700万 ダウンロード（前月は約9800万）があり、影響を受けるバージョンを使用している開発者・データサイエンティスト・企業は、秘密情報の漏洩、不意な副作用、またはシステム全体の乗っ取りリスクを軽減するために直ちにアップグレードすべきです。

本文

Cyata Research：LangChainにおけるLangChainの脆弱性

昨日、LangChainは私が langchain-core で報告した脆弱性（CVE‑2025‑68664 / GHSA‑c67j‑w6g6‑q2cm）について重大なアドバイザリを発表しました。

背景

今年初め、私の研究は「Vault Fault」作業で秘密管理者を破ることに焦点を当てました。これは、最も機密性の高い認証情報を守るために設計されたセキュリティ境界です。繰り返し登場した結論の一つは、プラットフォームが誤って攻撃者が作成したデータを信頼できる構造体として扱うと、その境界がすぐに崩れるということでした。今回「壊れる」対象は秘密管理者ではなく、それらを利用する可能性のあるエージェントフレームワークです。

なぜこの脆弱性が特別な注意を要するか

核心問題 – 脆弱なAPI（
```
dumps()
```
/
```
dumpd()
```
）は langchain-core 本体に存在し、ツールのバグや統合時のエッジケースではありません。
広範囲への影響 – ダウンロード量で見ると、LangChain は現在世界で最も広く展開されている AI フレームワークコンポーネントの一つです。2025年12月末時点で公開パッケージのテレメトリは数億インストール（≈847 M 総ダウンロード、過去1か月だけで約98 M）を示しています。
微妙なトリガー – 実際に発生するケースでは「攻撃者がシリアライズされたバイナリを送って
```
load()
```
を呼ぶ」というよりも、LLM の出力が
```
additional_kwargs
```
や
```
response_metadata
```
などのフィールドに影響し、その後フレームワーク標準機能（ストリーミングログ／イベント）で再シリアライズ・デシリアライズされるケースが多いです。単一のテキストプロンプトが思わぬ複雑な内部パイプラインへと波及します。

パッチ – バージョン 1.2.5 と 0.3.81 に修正が含まれています。生産環境で LangChain を使用している場合は、できるだけ早くアップデートしてください。

バグの短い概要

LangChain は内部シリアライズ形式として

'lc'

マーカーを持つ辞書を LangChain オブジェクトとみなします。脆弱性とは、

dumps()

と

dumpd()

が

'lc'

キーを含むユーザー制御の辞書を適切にエスケープしないことでした。
攻撃者が LangChain のオーケストレーションループで

'lc'

キーを持つコンテンツをシリアライズ・デシリアライズできれば、危険な任意オブジェクトを生成し、多くの攻撃者フレンドリー経路に踏み込む可能性があります。

アドバイザリでは 12 の異なる脆弱フロー が列挙されており、これらは非常に一般的なユースケース（例：イベントストリーミング、ロギング、メッセージ履歴／メモリ、キャッシュ）です。

最も深刻な結果

環境変数からの秘密抽出 –
```
secrets_from_env=True
```
でデシリアライズが行われると（昨日までがデフォルト）。
事前承認済み名前空間内でのオブジェクト生成（
```
langchain_core
```
,
```
langchain_openai
```
,
```
langchain_aws
```
,
```
langchain_anthropic
```
など）で、コンストラクタ側に副作用（ネットワーク呼び出し、ファイル操作）が発生する可能性。
特定条件下での任意コード実行。

CWE‑502：信頼できないデータのデシリアライズ、CVSS 9.3（クリティカル）。

私の研究ストーリー

質問から始めました：「AI アプリケーションにおける信頼境界はどこにあり、開発者はそれらを本当に理解しているのでしょうか？」
デシリアライズを明確な攻撃対象として注目。
攻撃者制御のデシリアライズが環境変数を盗み出すブラインド SSRF を誘発できると仮定。
バグは悪質なコードではなく コードの欠如 でした：
```
dumps()
```
が
```
'lc'
```
キーを持つユーザー制御辞書をエスケープしませんでした。

技術的詳細

1. 背景：

'lc'

マーカーとその存在意義

LangChain は特定オブジェクトを構造化された dict 形式でシリアライズします。
```
'lc'
```
キーは「これは LangChain シリアライズ構造体です」を示します。
```
'lc'
```
を含む可能性のあるユーザー制御データは慎重に扱わなければ、攻撃者が内部オブジェクトを装った辞書を作成し、デシリアライザを騙せます。

2. パッチ

シリアライズ時に

'lc'

キーを含む単純な dict をエスケープ（ラップ）することで、実際の LangChain シリアライズオブジェクトとの混同を防止します。

3. ホワイトリスト

```
load()
```
/
```
loads()
```
は任意クラスを生成せず、
```
langchain_core
```
,
```
langchain_openai
```
,
```
langchain_aws
```
等のエコシステムパッケージからのクラスのみ許可しています。
ほとんどの許可クラスは安全なコンストラクタですが、一部（例：
```
ChatBedrockConverse
```
) はインスタンス化時にネットワーク呼び出しを行います。

4. 情報漏洩経路

loads()

はデシリアライズ中に環境変数から値を解決する秘密型をサポートします。パッチ前は

secrets_from_env

がデフォルトで有効でした：

if (
    value.get("lc") == 1
    and value.get("type") == "secret"
    and value.get("id") is not None
):
    key = value["id"]
    if key in self.secrets_map:
        return self.secrets_map[key]
    if self.secrets_from_env and key in os.environ and os.environ[key]:
        return os.environ[key]   # <-- 環境変数を返す

攻撃者は

ChatBedrockConverse

のようなクラス（デフォルトホワイトリストに含まれる）を生成し、アウトバウンド GET リクエストを送ることができます。

secrets_from_env

が有効だと、任意の環境変数をリクエストヘッダーに注入でき、秘密情報が漏洩します。

5. Jinja2 テンプレート経由でのコード実行

```
PromptTemplate
```
クラス（ホワイトリスト内）ではテンプレートからプロンプトを生成し、その一形態として Jinja2 を使用。
Jinja2 のレンダリングは任意 Python コードを実行できるため、直接的に
```
loads()
```
で発動するわけではありませんが、デシリアライズ後のオブジェクト呼び出しで実行される可能性があります。

対象範囲 – 実務チェックリスト

アプリケーションが脆弱な langchain-core バージョンを使用している場合に曝露されます。12 の脆弱フローは次のようなパターンです：

```
astream_events(version="v1")
```
（v1 は脆弱、v2 は非脆弱）
```
Runnable.astream_log()
```
信頼できないデータに対する
```
dumps() / dumpd()
```
その後
```
load() / loads()
```
デシリアライズ時の信頼できない入力
内部シリアライズフロー（
```
RunnableWithMessageHistory
```
,
```
InMemoryVectorStore.load()
```
, 特定キャッシュ, LangChain Hub の
```
hub.pull
```
等）

推奨：パッチ適用済みバージョンへアップグレード。実際に動作している環境が修正コードを使用しているか確認してください。

本番環境での対策 – 防御指針

まずはパッチ – langchain-core を修正版に更新し、すべての環境でインストールされているバージョンを検証。
LLM 出力は攻撃者制御とみなす –
```
additional_kwargs
```
,
```
response_metadata
```
, ツール出力, 取得ドキュメント, メッセージ履歴などを、再シリアライズ・ロードされるストリーミングログ／イベントで信頼できないものとして扱う。
秘密解決機能の見直し – アップグレード後は「環境変数から秘密を解決する」設定を無効にしておくか、受け取るデータが安全であることを確認。

LangChainJS の並行ケース

LangChainJS でも類似のアドバイザリ（GHSA‑r399‑636x‑v7f6 / CVE‑2025‑68665）があり、同様のメカニズムです。Python と JavaScript 両方を運用している組織は、このパターンがエコシステム横断で存在することを念頭に置いてください。

LangChain を超えて重要な理由

エージェント型 AI フレームワークは、プロダクションシステム内の重要インフラへと変わっています。シリアライズ形式・オーケストレーションパイプライン・ツール実行・キャッシュ・トレーシングは「配管」ではなく、安全境界そのものです。この脆弱性は単なるライブラリバグではなく、より広いパターンのケーススタディです：

アプリケーションが安全に生成したと信じるデータをデシリアライズする際、その出力に LLM が生成した不正入力（プロンプトインジェクション等）が含まれる可能性。
内部マーカーとして使われる予約キーが、秘密情報や実行近接挙動へのピボット点になる。

AI ガバナンスへの示唆

セキュリティリーダーは次の問いを投げかけるべきです：

どこでエージェントを使用しているか？
プロダクションにデプロイされているバージョンは？
どのサービスが機密秘密へアクセスできるか？
LLM 出力がその境界を越える場所は？

これらは可視化とガバナンス問題であり、単なる開発者の課題ではありません。

Cyata が提供する支援 – 可視化・リスク評価・制御・ガバナンス

フォーカス	提供内容
可視化	実行中のもの、場所、接続状況を把握。フレームワーク、パッケージ、バージョンを追跡。
リスク評価	現実世界での爆発半径に基づき優先順位付け。最高リスクパス（信頼できないコンテンツが特権環境へ）を特定。
制御	リスクあるパターン（例：信頼できないデータのデシリアライズ）のガードレールを強化。敏感機能を不正な文脈でブロック。
ガバナンス	承認済みフレームワーク・バージョン・設定に関するポリシー定義、逸脱監視、監査ログ提供。

開示タイムライン

レポート提出（Huntr） – 2025年12月4日
LangChain メンテナの承認 – 2025年12月5日
アドバイザリ・CVE 公開 – 2025年12月24日

同じ日のほかのニュース

一覧に戻る →

2025/12/26 8:13

おそらく、デフォルト設定が高すぎる可能性があります。

## Japanese Translation: **（すべての重要ポイントを統合し、明確さを保つ）** --- ### 要約著者は『ロード・オブ・ザ・リング』を声に出して読むことに二か月を費やし、第1部の終わりまで達しました。文ごとに「通常の時間の3倍」を意図的に遅く読むことで、口速で読むアプローチが急ぎを防ぎ、興味を高め、理解・没入・楽しみを深めることに気づきました。トールキンのイメージとムードは、ゆっくり読んだときにのみ心に完全に広がります。彼はこの洞察を読み以外にも拡張します。食事を通常の速度の1/3または半分に遅らせると、食べ物への感謝が増し、掃除機をかけたり、メールをチェックしたり、リストを書いたりする際も急いで行うより満足度が高くなります。現代生活の無限の消費物は、高速摂取を促進し、本や食べ物、情報の完全な鑑賞を損ないます。「少ないほど良い」という格言は、過剰に早く消費するとその影響力を失います。著者は、遅らせることで味覚と好みが変わり、濃密な文学作品や自家製料理が加工品より豊かになることもあると指摘します。今日の文化的規範はTikTokクリップ、加工食品、CGI映画などの高速で光沢のある消費を優先し、深い関与を犠牲にしています。彼は読者に対して、通常速度の約1/3程度と極端に遅く消費する実験を行い、報酬が増える体験を促します。Raptitude読者向けに「アルコール・ソーシャルメディア・スナックなどを一か月間やめる」討論フォーラムを開設し、多くの人が1月に同様のイニシアチブへの関心を示しています。

2025/12/26 10:02

**MiniMax M2.1:** *実世界の複雑タスクに対応するために設計された―多言語プログラミング*

## Japanese Translation: ```markdown ## Summary MiniMaxは新しいM2.1 AI‑nativeモデルをリリースし、Rust、Java、Go、C++、Kotlin、Objective‑C、TypeScript、JavaScriptなど複数言語にわたる実世界のプログラミングとオフィス作業で明確なパフォーマンス向上を提供します。主な強みは以下の通りです： - **多言語マスタリー**：Claude Sonnet 4.5およびGemini 3 Proを上回るベンチマークスコアを持ち、マルチランゲージコーディングタスクで最高レベル。全体的にはClaude Opus 4.5に近い性能。 - **WebDev & AppDevの進化**：ネイティブAndroid/iOS開発サポート、デザイン理解と美的表現の向上、3D科学シミュレーション、高品質ビジュアライゼーションによる持続可能なワークフロー。 - **インタリーブド・シンキング**：複合指示処理が改善され、オフィス環境での使い勝手を向上。 - **トークン効率的返信**：トークン消費を削減し応答時間を短縮、コーディングワークフローの効率化。 M2.1はまたVIBEベンチマーク（Web, Simulation, Android, iOS, Backend）も導入し、平均スコア88.6でClaude Opus 4.5にほぼ匹敵し、多くのサブセットでSonnet 4.5を上回ります。 Factory、Fireworks、Cline、Kilo、RooCodeなど国際AIプラットフォームからは速度、信頼性、多言語安定性、コスト効率が高いと評価されています。モデルは2つのAPIバージョンで利用可能です：**M2.1**（フル機能）および **M2.1‑lightning**（同じ結果を持ちつつ高速推論）。どちらも自動キャッシュをサポートし、開発者体験をスムーズにします。オープンソースウェイトはHugging Faceにホストされており、MiniMaxはさらにオープンソースの提供拡大とエージェントフレームワークやコンテキスト管理ツールへのサポート拡充を計画しています。開発者と企業向けにM2.1はより効率的なコーディング支援、トークンコストの削減、および強化された多言語機能を提供し、ソフトウェア納品タイムラインの加速やAI開発エコシステムにおける運用費用の低減を可能にします。 ```

2025/12/25 22:02

Windows x86‑64 用の Python 3.15 インタプリタは、ほぼ 15 ％速くなる見込みです。

## Japanese Translation: ## Summary Ken Jinは、macOS AArch64（XCode Clang）およびWindows x86‑64（MSVC）のCPythonのターミナル呼び出しインタープリターに関する以前の実績主張を部分的に撤回したものの、測定可能な速度向上を報告しています。macOSでは約5 %、Windowsでは実験的な内部MSVCビルドで最大15–16 %の改善が確認されています。ベンチマークは、「tail‑call threaded」インタープリターが従来のcomputed‑gotoループよりも優れていることを示しています。現代のコンパイラではその差は縮小しますが、実験的なVS 2026ビルドでは幾何平均で約16 %の利得が確認されています。この改善は、短いインタープリター・ループによりコンパイラがヘルパー関数（例：`PyStackRef_CLOSE_SPECIALIZED`）をインライン化し、レジスタ圧力を減らすことから生じています。ターミナル呼び出しは、Josh HabermanのProtobufブログとHaoran XuによるClangの `__attribute__((musttail))` を使用したコピー＆パッチ手法で広まりました。XCode Clangが修正されたCPython 3.14/3.15ではmacOS上で約5 %の速度向上が示され、Python 3.15「What's New」には長いスクリプトに対して最大40 %の速度向上が記載されています。MSVCチーム（Chris Eibl、Brandt Bucher）がリリースしたVisual Studio 2026はターミナル呼び出しをサポートし、具体的な利得をもたらします：spectralnorm_tc 1.48倍速、nbody_tc 1.35倍速、bm_django_template_tc 1.18倍速、xdsl_tc 1.14倍速。速度向上はPython 3.15まで継続すると予想されます。機能がロールバックされない限り、macOSのバイナリにはターミナル呼び出しが有効化された状態で配布され、VS 2026を使用したWindowsビルドでも同様の利得が期待できます。CPythonコミュニティはさらにビルドフラグ（`--tail-call-interp`）を洗練させ、プロファイルガイド付き最適化（PGO）を統合して性能を向上させる可能性があります。 CPUバウンドのPythonワークロード（科学計算、ウェブフレームワークなど）を実行するユーザーは、わずかな速度改善に気付くかもしれません。Pythonバイナリを配布する企業はコード変更なしで高速な実行ファイルを提供でき、Visual Studioを使用するWindowsの開発者もランタイム効率の向上から恩恵を受けるでしょう。