Skip to content
catch-all-favorite
Esc
navigateopen⌘Jpreview
On this page

Lodash の脆弱性レポート(CVE-2025-13465)

調査日: 2026-04-15 ステータス: Published (GitHub Advisory: Reviewed 2026-01-21)

概要

Lodash の _.unset および _.omit 関数にプロトタイプ汚染(Prototype Pollution)の脆弱性が存在する。攻撃者が細工されたパス(例: __proto__.toString)を渡すことで、グローバルプロトタイプ上のメソッドを削除できる。上書きはできないが、toString などの基本メソッドが削除されるとアプリケーション全体がクラッシュするなどの影響がある。

基本情報

項目 内容
CVE ID CVE-2025-13465
GHSA ID GHSA-xxjr-mmjv-4gpg
CVSS v4.0 スコア 6.9 (Moderate)
CVSS ベクター CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:H/SI:H/SA:H/E:P
CWE CWE-1321: Improperly Controlled Modification of Object Prototype Attributes (‘Prototype Pollution’)
公開日 2026-01-21
最終更新日 2026-01-21

影響を受けるソフトウェア

lodash (npm)

  • ベンダー: lodash
  • 影響バージョン: >= 4.0.0, < 4.17.23
  • 修正バージョン: 4.17.23
  • 修正コミット: edadd45

lodash-es (npm)

  • ベンダー: lodash
  • 影響バージョン: >= 4.0.0, < 4.17.23
  • 修正バージョン: 4.17.23

lodash-amd (npm)

  • ベンダー: lodash
  • 影響バージョン: >= 4.0.0, < 4.17.23
  • 修正バージョン: 4.17.23

lodash.unset (npm)

  • ベンダー: lodash
  • 影響バージョン: >= 4.0.0, <= 4.5.2
  • 修正バージョン: パッチ未提供(個別パッケージは修正されていない)

脆弱性の詳細

根本原因

_.unset(object, path) は内部関数 baseUnset を通じてオブジェクトからプロパティを削除する。パッチ前の baseUnset は受け取ったパスのバリデーションが不十分で、__proto__constructor.prototype をセグメントに含むパスをそのまま辿ってしまっていた。_.omit も内部で同じ削除ロジックを使用しているため同様に脆弱である。

攻撃の流れ

  1. アプリケーションが外部から受け取った文字列パスを _.unset(state, userInput) のように _.unset / _.omit のパス引数に渡している
  2. 攻撃者がパスとして __proto__.toString を送り込む
  3. baseUnsetobj.__proto__.toString(= Object.prototype.toString)を削除する
  4. アプリケーション内のすべてのオブジェクトtoString メソッドを失う
const _ = require('lodash');

const obj = {};
_.unset(obj, '__proto__.toString');

// グローバルに影響する
({}).toString();          // TypeError: (intermediate value).toString is not a function
String({});               // TypeError と同様に失敗
console.log({});          // 多くのケースで例外

「削除のみ」という制約とその二次被害

本脆弱性は典型的な Prototype Pollution(任意のプロパティを追加/上書きして認可バイパス等を行う)とは異なり、削除しか行えない。しかし削除でも以下の影響がある:

  • 可用性: toString, hasOwnProperty, valueOf など広く利用される基本メソッドが消えると、テンプレートリテラル展開・配列の joinconsole.log・JSON 変換などが連鎖的に失敗し、プロセスやタブが停止する
  • 整合性: hasOwnProperty の存在を前提とした認可・バリデーションロジックが想定外の分岐を取る可能性
  • 復旧困難: グローバルプロトタイプは一度破壊されるとプロセス/タブの再起動まで復旧しない

CVSS v4.0 のベクターでも Subsequent System 系の影響が SC:H/SI:H/SA:H(機密性・整合性・可用性いずれも高)と評価されており、プロトタイプ連鎖を介して広範囲に波及する性質が反映されている。

対策・推奨事項

  • lodash / lodash-es / lodash-amd を 4.17.23 以降にアップグレードする(最優先)
  • 推移的依存(transitive dependencies)を確認する
    npm ls lodash
    npm ls lodash-es
    pnpm why lodash
    アップデートできない直接依存がある場合は、npm の overrides / yarn の resolutions / pnpm の pnpm.overrides で強制的に引き上げる
  • ユーザー入力のパスを直接渡さない: _.unset / _.omit のパス引数は信頼できる入力のみに限定する。外部入力を使う場合は __proto__ / constructor / prototype を含むパスを拒否するバリデーションを挟む
  • 個別パッケージ lodash.unset を使っている場合はパッチが提供されていないため、lodash 本体に切り替えたうえで 4.17.23 以降を導入するか、呼び出し部で入力検証を行う
  • SCA ツールで棚卸し: npm audit / pnpm audit / yarn audit、Dependabot、Renovate、Snyk などで依存グラフ全体を走査する

フロントエンド影響分析

Lodash は歴史的にブラウザとサーバー双方で使用されるフロントエンド関連ライブラリであり、脆弱なコードパス自体は環境を問わず動作する。ただし、攻撃者が _.unset / _.omit のパス引数に到達する経路や、プロトタイプ汚染の影響範囲は実行環境によって大きく異なる。CVSS 6.9(中)は両環境を平均した値であり、構成ごとに独立して影響度を評価する必要がある。

構成 影響度 対処要否 備考
SPA(クライアントサイドのみ) 🟡 中 推奨 脆弱コードパスはブラウザでも動作する。ただし攻撃者が自オリジンの _.unset 呼び出しに任意文字列を注入するには別途 XSS 等が必要。影響範囲はその 1 ユーザーの 1 タブに限定される
SSR(サーバーサイドレンダリング) 🔴 高 要対処 Node.js 環境では単一のリクエストでプロセス全体のプロトタイプを破壊でき、全利用者のリクエスト処理が停止する。リモート攻撃者が未認証で単発の DoS を成立させ得る

判定の考え方

1. ブラウザのセキュリティ境界(SPA 判定で最重要)

典型的な SSRF / プロキシバイパス系の CVE とは異なり、本脆弱性はブラウザの同一オリジンポリシー・CORS・ネットワークサンドボックスによって緩和されない。理由は以下。

  • 攻撃チェーンがクライアント内で完結: プロトタイプ汚染は JavaScript ランタイム内部の操作で、ネットワークリクエストを伴わない。したがって「内部アドレスに届かない」「クロスオリジンで読めない」といったブラウザ境界は影響しない
  • CSP も直接は無関係: 新規スクリプトの実行ではなく、既存コードが自身のプロトタイプを破壊する形のため、script-src などの CSP ディレクティブでは防げない

一方、SPA で影響度を即「高」と評価しないのは、攻撃者が任意の文字列を _.unset / _.omit のパス引数に到達させる経路が SPA では限定的だからである。

  • SPA でユーザー入力が lodash のパスに渡るケースは、動的フォームビルダーや JSON パッチ系ライブラリの一部など限定的
  • URL クエリやハッシュが lodash に渡る設計でない限り、攻撃者がクロスユーザー攻撃を成立させるには別途 XSS が必要
  • それらの前提があっても、自己 DoS(自分のタブが固まる)に留まる設計では実害は低い

ただし、ブラウザ環境であっても React / Vue / 他のライブラリ群が Object.prototype のメソッドに依存しているため、一度汚染されると同一タブ内のすべてのライブラリが連鎖的に壊れる。このため「🟢 低」ではなく「🟡 中」と判定した。

2. 実行環境の違い

  • SPA(ブラウザ): 影響はその 1 ユーザーの 1 タブ内で完結する。別タブや別ユーザーには波及しない
  • SSR(Node.js): 単一プロセスが多数のユーザーリクエストを処理するため、プロトタイプ破壊 = 全ユーザー影響。かつ API サーバで _.unset(state, req.body.path) のような設計は実際に発見されやすい

3. 攻撃ベクターと前提条件

  • 攻撃ベクター: ネットワーク経由(AV:N)、認証不要(PR:N)、ユーザー操作不要(UI:N)
  • 前提条件: アプリケーションが外部入力を _.unset / _.omit のパス引数に渡していること
    • SSR: API ボディ / クエリ経由で到達しやすい
    • SPA: URL ハッシュ / postMessage / 別 XSS 経由など間接的

4. ランタイム vs ビルドタイム

  • lodash はランタイムライブラリで、ビルド時のみの影響はない
  • ビルドツール自体が lodash を使用している場合(webpack 等)は、ビルドサーバーがサーバー環境として扱われるため SSR 相当の評価が必要だが、ビルド時に外部入力が lodash に到達する経路はまれ

参考リンク

情報ソース

ソース 取得状況
NVD (NIST) ❌ 取得不可(WebFetch が 403 で拒否。検索結果でページの存在のみ確認)
GitHub Advisory ✅ 取得済み(GHSA-xxjr-mmjv-4gpg および Lodash 本家 Security Advisory の両方)
Web検索 ✅ 取得済み

Was this page helpful?