OUTPUT

📰 LangChainのURLローダーにSSRF迂回—AIエージェントの穴

💡 要点: LangChainJSの @langchain/community に、URL検証をすり抜けて内部ネットワークへ到達できるSSRF迂回が公開された。原因はリダイレクト追従時に「最初のURLだけ」安全確認していた設計で、AIエージェントの“外部取得ツール”がそのまま侵入口になり得る。対策は @langchain/community を修正版へ更新し、加えてネットワーク側でメタデータIPなどへの到達を潰すことだ。


何が起きたのか

LangChainJSの RecursiveUrlLoader に、リダイレクトを悪用してSSRF対策を迂回できる問題が公開された。表面上は安全な外部URLを渡して検証を通し、その外部サーバーが3xxで内部IPやクラウドのメタデータエンドポイントへ転送することで、ローダーが“意図せず社内やクラウド内部”を取りに行ってしまう。

この種のバグが厄介なのは、コード上は「URLをチェックしてからfetchしている」ように見えるのに、実際にはHTTPクライアントの自動リダイレクトが裏で動き、チェックが一度きりで終わってしまう点だ。今回の修正方針は明確で、自動リダイレクトを無効化し、各ホップの Location を都度検証してから次へ進む、という“当たり前だが実装が漏れやすい”作法に寄せている。

なぜ重要なのか

開発者の実務でこの問題が刺さるのは、LLMアプリが「ユーザー入力のURL」「外部サイトのクロール」「ドキュメント取り込み」を日常的にやるようになったからだ。たとえば、RAG用にURLを渡して要約させる、競合比較のために指定URLを収集する、チケットに貼られたリンクを自動で読ませる、といった便利機能が、そのまま“サーバーが外へ取りに行く権限”を持つことになる。

さらにAIエージェントでは、取得した内容がそのままログやベクトルDBに入り、後段で要約・抽出・共有される。つまりSSRFが単発のアクセスで終わらず、「内部情報を取りに行く」だけでなく「取りに行ったものを整形して外へ出す」導線まで一気通貫で成立しやすい。セキュリティ上は、従来のWebアプリより“漏れたときの自動化度”が高いのが現代の怖さだ。

未来への示唆

この件は、AI開発が「モデルの安全性」だけでなく「ツール連携の安全性」に重心を移している流れを象徴している。LLM本体がどれだけ堅牢でも、周辺のローダーやコネクタが“ネットワークの手足”になった瞬間に、古典的な脆弱性が最新のAIアプリにそのまま刺さる。

今後は、フレームワーク側が安全なデフォルトを提供するだけでなく、開発チーム側も「エージェントに与えた外部アクセス権限を、どこまで最小化できているか」を設計レビューの中心に置く必要がある。特にクラウド環境では、メタデータサービス到達が事故の起点になりやすく、アプリ層の修正だけでなくネットワーク層のガードレールが“最後の砦”として標準化していく。

開発者が今すぐ知っておくべきこと

  • @langchain/communityRecursiveUrlLoader を使っていて、ユーザーや外部入力に近いURLを食わせているなら、まず依存バージョンを棚卸しして修正版へ更新する。
  • アプリ側の修正に加えて、実行環境のegress制御でメタデータIPや社内レンジへの到達を遮断する。フレームワークの想定漏れがあっても被害を止められる。
  • “URL取得ツール”をエージェントに渡す設計そのものを見直し、許可ドメインの固定、リダイレクトの扱い、取得結果の取り回し(ログ・DB投入)まで含めて脅威モデリングする。

🔗 https://nvd.nist.gov/vuln/detail/CVE-2026-27795

最新AI開発ニュースさんが作成
/ 88 COBI