JavaScriptエコシステムの根幹を担うライブラリに、見過ごしてはいけない重大な欠陥が発見された。npmで週平均約5000万回ダウンロードされる protobuf.js に、任意コード実行（RCE）を可能にする脆弱性が存在することが明らかになった。しかもPoC（概念実証コード）はすでに公開されており、攻撃の敷居は決して高くない。

protobuf.jsとは何か

Protocol Buffers（Protobuf）はGoogleが開発したバイナリシリアライズ形式で、マイクロサービス間通信やリアルタイムアプリ、クラウド環境でのデータ格納に広く使われている。protobuf.js はそのJavaScript/TypeScript実装であり、Node.jsベースのバックエンドや各種クラウドファンクションに深く組み込まれているケースが多い。「使ってるつもりのないライブラリ」として依存関係の奥底に潜んでいることも珍しくない。

脆弱性の仕組み

今回の脆弱性はGitHub Security Advisory ID GHSA-xq3m-2v4x-88gg として追跡されている（CVE番号は未採番）。アプリケーションセキュリティ企業Endor Labsが4月18日に詳細レポートを公開した。

問題の本質は 動的コード生成の不備 だ。protobuf.js はprotobufスキーマからJavaScript関数を生成する際、文字列を連結した上で Function() コンストラクタを通じてそのまま実行する設計になっている。ここでメッセージ名などのスキーマ由来の識別子をサニタイズしていないため、攻撃者が細工したスキーマを与えると任意のコードを生成関数に埋め込むことができる。

具体的な攻撃シナリオはこうだ：

  • 攻撃者が悪意あるスキーマを用意する
  • アプリケーションがそのスキーマを読み込む
  • スキーマ処理時に埋め込まれたコードが実行される
  • 環境変数・認証情報・内部データベースへのアクセスが可能になり、インフラ内の横展開（ラテラルムーブメント）にまで至る

サーバーサイドだけでなく、開発者のローカルマシンが攻撃対象になるケースも想定されている。信頼できないスキーマをローカルでデコードする習慣がある開発環境は要注意だ。

影響バージョンと修正版

ブランチ 影響バージョン 修正版 npm反映日

8.x 8.0.0以下 8.0.1 2026-04-04

7.x 7.5.4以下 7.5.5 2026-04-15

脆弱性報告は3月2日、パッチのGitHub公開が3月11日、npmへの反映が4月4日（8.x）と4月15日（7.x）だ。npm反映まで最大6週間のラグがあった点は覚えておいてほしい。

修正の内容はスキーマ識別子から英数字以外の文字を除去するサニタイズ処理の追加だが、Endor Labsは「長期的には Function() に攻撃者が到達できる識別子を通さない設計に変えることが根本対策」と指摘している。現在のパッチは「有効だが暫定的」と見るべきだろう。

実務への影響

今すぐやること：

  • npm list protobuf または npm ls protobufjs で直接・間接の依存を確認する
  • 使用中なら 8.0.1 または 7.5.5 に即時アップグレード
  • 直接依存でなくても推移的依存（transitive dependency）として含まれている可能性があるため、npm audit でのスキャンも実施する

中期的に取り組むこと：

  • スキーマのロードを「信頼できない入力」として扱う設計に見直す。外部から受け取ったスキーマを動的に読み込む構成は本質的にリスクを持つ
  • 本番環境では コンパイル済み・静的スキーマを優先する（Endor Labsも同様に推奨）
  • 依存ライブラリの定期監査をCI/CDパイプラインに組み込む。今回のようにPoC公開後に初めて気づく状況は避けたい

サプライチェーンリスクの観点：

週5000万ダウンロードというスケールは、このライブラリが「見えないインフラ」として世界中の本番環境に組み込まれていることを意味する。今回は積極的な悪用は確認されていないが、PoC公開済みの状態で「まだ攻撃がないから大丈夫」は通用しない。

筆者の見解

セキュリティの話は得意分野ではないが、こういうケースは技術的に興味深い。問題の構造が非常に典型的だからだ。

Function() コンストラクタによる動的コード生成は、JavaScriptの世界では eval() と同列のリスクとして長年語られてきた。「スキーマは自分たちが管理するもの」という前提で設計されたコードが、攻撃者がスキーマを制御できる環境では一気に危険な武器になる——これはまさに「信頼境界の設計ミス」の典型例だ。

今回Endor Labsが指摘した「根本対策は Function() に攻撃者到達可能な値を渡さないこと」という提言は、技術的には正しい。しかし実装を変えるのは容易ではなく、現実的なトレードオフの中でパッチを選択した判断も理解できる。

日本のエンタープライズ現場で気になるのは、こういった脆弱性情報が「npmを使っているチームの話」として遠い存在に聞こえてしまうパターンだ。実際には、Azureのバックエンドサービスやクラウドネイティブ構成の中に protobuf.js が潜んでいることは珍しくない。依存関係の見通しが悪いまま運用しているシステムが、このような脆弱性の前では丸裸になる。

「今動いているから大丈夫」ではない。依存ライブラリの監査を継続的なプロセスとして組み込んでいる組織とそうでない組織の差は、こういった局面で如実に現れる。まずは npm audit を今日実行することから始めてほしい。

出典: この記事は Critical flaw in Protobuf library enables JavaScript code execution の内容をもとに、筆者の見解を加えて独自に執筆したものです。