pnpmに乗っ取り級の脆弱性2件、利用者は最新版へ更新を CVE-2026-55698

プログラム開発でよく使われるパッケージ管理ツール「pnpm（ピーエヌピーエム）」に、危険度の高い欠陥が2件見つかりました。いずれも、悪意のあるプログラム部品やプロジェクトを取り込んだだけで、開発者のパソコンを乗っ取られ、勝手にプログラムを実行されてしまう恐れがあります。

2件はどちらも、危険度を10段階で示す国際指標（CVSS）で10点満点中8.8点と評価されました。米国立標準技術研究所が運用する脆弱性データベース（NVD）にも、2026年6月25日付で CVE-2026-55698 と CVE-2026-50016 として登録されています。CVEとは、世界共通で脆弱性に振られる管理番号のことです。

開発元はすでに修正版を公開しています。pnpmを使っている人は、10系なら10.34.2以上、11系なら11.5.3以上へ早めに更新してください。やっかいなのは、これまで「安全策」とされてきた設定をオンにしていても防げない点です。順を追って説明します。

そもそもpnpmとは何か

pnpmは、JavaScript（Webサイトやアプリの開発で最も広く使われるプログラミング言語）の開発で、外部のプログラム部品（パッケージ）を取りまとめてインストールする道具です。同じ役割の「npm」やyarnの仲間で、ディスク使用量が少なく動作が速いことから、近年は大手企業の開発現場でも採用が増えています。

現代のソフトウェアは、自前のコードよりも他人が公開した部品の寄せ集めでできています。1つのアプリが数百〜数千もの部品に依存することは珍しくありません。その部品をまとめて取ってくる入り口がpnpmのようなツールです。つまり、ここに欠陥があると、取り込む部品やプロジェクトを通じて、開発者のパソコンが一斉に狙われることになります。こうした「部品の流通経路を悪用する攻撃」を、サプライチェーン攻撃と呼びます。

見つかった2件の欠陥

今回NVDに登録されたのは次の2件です。どちらも、攻撃に特別な権限は不要で、ネットワーク越しに成立します。成立には「利用者が悪意のあるパッケージやプロジェクトを取り込む」という操作が必要ですが、これは日々の開発で当たり前に行われている作業です。

2件を両方ふさぐには、10系なら10.34.2以上、11系なら11.5.3以上が必要です。なお開発元は、この2件を含むサプライチェーン関連の修正を6月にまとめて何件も公開しています。後述するように、できれば最新版まで上げておくのが安全です。

誰が、何のために狙うのか

この欠陥を実際に使うのは、公開されているプログラム部品の置き場（レジストリ）や、誰でも閲覧できるソースコードの中に、わなを仕込める攻撃者です。自分で部品を1つ公開するだけ、あるいは人気プロジェクトの偽物や改造版を1つ用意するだけで、わなは完成します。高度な技術や内部関係者である必要はありません。

その攻撃者が狙うのは、その部品やプロジェクトを取り込んだ開発者のパソコンや、自動でビルドを回す社内サーバー（CI環境）の上で、こっそり自分のプログラムを動かすことです。一度入り込めば、ソースコードや認証情報を抜き取ったり、配布前の製品に裏口を仕込んだりと、被害は一気に下流へ広がります。

怖いのは、被害が開発者個人にとどまらないことです。汚染された開発環境からビルドされたアプリやサービスは、それを使う一般の利用者にまで危険を運びます。実際、世界中で使われていたプログラム部品が乗っ取られ、取り込んだ企業が連鎖的に被害を受けた事例は、通信部品「axios」の偽パッケージ事件や、目に見えないコードを仕込む「GlassWorm」など、ここ1年だけでも繰り返し起きています。今回は、その入り口であるツール自体に穴が空いたという点で性質が重くなります。

CVE-2026-55698：pnpm本体が偽物にすり替わる

2件のうち、より不気味なのがこちらです。報告したのは、pnpmの作者であるZoltan Kochan氏（zkochan）本人で、公式の注意喚起（アドバイザリ）として公開されました。

背景には、pnpmが持つ「バージョン自動切り替え」という便利機能があります。プロジェクトごとに「このプロジェクトはpnpmのこのバージョンで動かす」と指定しておくと、開発者が古いpnpmを使っていても、必要なバージョンを自動で取りに行って切り替えてくれる仕組みです。チーム全員が同じ環境で開発できるよう用意された機能です。

問題は、この自動切り替えの判断材料が、プロジェクト内のロックファイル（pnpm-lock.yaml。使う部品の正確なバージョンを記録した台帳ファイル）に書かれていた点です。攻撃者がこの台帳の中の「起動用の情報（bootstrapメタデータ）」を細工しておくと、pnpmは検証を十分にしないまま、台帳が指し示すpnpm本体を信頼してしまいます。その結果、本物のpnpmだと思って実行したものが、実は攻撃者がすり替えた偽のpnpmだった、という事態が起こります。利用者が悪意あるプロジェクトの中で何気なくpnpmコマンドを打った瞬間に、攻撃者のプログラムが動き出すわけです。

修正版では、自動切り替えの際に取得した本体が正規に署名されたものかどうかを検証し、署名が一致しなければ実行を拒否するよう改められました。影響を受けるのは10.34.2より前と、11.0.0以上11.5.3より前のバージョンです。

CVE-2026-50016：悪意ある部品がgitの仕掛けを乗っ取る

もう1件は、悪意のあるプログラム部品を1つインストールするだけで成立します。報告したのは、Web系の脆弱性研究で知られるaszx87410氏で、こちらも公式アドバイザリとして公開されています。

仕組みはこうです。部品には、別の部品を「別名（エイリアス）」として呼び出す設定を書けます。攻撃者はこの別名に、@x/../../../../../.git/hooks のように、上の階層へさかのぼる記号（../）を大量に混ぜた文字列を仕込みます。pnpmはこの別名を、本来は部品を置くべきフォルダの名前としてそのまま使ってしまうため、指定したフォルダの外へ抜け出して、プロジェクト内の好きな場所を書き換えられるのです。これは「パストラバーサル（ディレクトリの境界を越える攻撃）」と呼ばれる古典的な手口です。

攻撃者が書き換え先に選ぶのが、gitの「フック」と呼ばれる場所です。フックとは、コミットやプッシュなどの操作のたびに自動で走る小さなプログラムのこと。ここを攻撃者管理下の中身へのショートカット（シンボリックリンク）に置き換えておくと、開発者が次にgit操作をした瞬間に、攻撃者のプログラムが実行されてしまいます。影響を受けるのは10.34.0より前と、11.0.0以上11.4.0より前です。

「スクリプトを止めているから安全」が通じない

npm系のツールには昔から、悪意ある部品が「インストール時に自動で走るプログラム（ライフサイクルスクリプト）」を仕込み、その場でコードを実行する攻撃がありました。その対策として、自動実行を止める --ignore-scripts という設定が広く使われています。pnpmはさらに進んで、バージョン11で初期設定のまま自動実行を止めるなど、サプライチェーン対策を強化してきました。npm側でも自動実行を既定で止める方向に舵を切っています。

ところが今回の2件は、いずれもこの「スクリプトを止める」対策をすり抜けます。CVE-2026-50016の公式説明では、自動実行を止める設定（--ignore-scripts）を付けていても攻撃が成立すると明記されています。フォルダの境界を越える書き換えや、ツール本体のすり替えは、スクリプトの自動実行とは別の経路で起こるためです。「安全策をオンにしているから大丈夫」とは言い切れない、というのが今回の重い点です。だからこそ、設定の見直しではなく本体の更新が必要になります。

自分は影響を受けるのか、どう対処するか

まず、いま使っているpnpmのバージョンを確認します。ターミナルで pnpm --version と打てば表示されます。下の早見表で、自分のバージョンが影響範囲に入っていないかを確かめてください。

更新方法は環境によって異なります。npm install -g pnpm@latest で入れ直すか、Node.js同梱のCorepackで管理している場合は corepack prepare pnpm@latest --activate を使います。プロジェクトのpnpmバージョンを package.json の packageManager 欄で固定している場合は、その値も合わせて引き上げてください。

注意したいのは、今回の2件はpnpmが6月に出した一連のセキュリティ修正のうちの一部だという点です。公式のアドバイザリ一覧には、フォルダ境界を越える書き換えやインストール処理の不備など、別の修正もまとまって並んでいます。これらの中にはさらに後のバージョン（10.34.4や11.7.0以降）で直されたものもあるため、2件をふさぐだけで満足せず、可能なら最新版まで上げておくのが安全です。自分のプロジェクトが取り込んでいる部品に問題がないかを点検したい場合は、依存ファイルを貼るだけで脆弱性を調べられるスキャナーも活用できます。

確認しておきたい点

部品を取りまとめる入り口こそ狙われる

今回の2件は、いずれも「悪意ある部品やプロジェクトを取り込む」という、開発の日常そのものを足がかりにします。しかも、これまで効くとされてきた自動実行の停止策をすり抜けるため、設定の見直しだけでは防げません。対策は本体の更新に尽きます。10系は10.34.2以上、11系は11.5.3以上、できれば最新版へ。これだけで2件はふさげます。

部品を1つずつ点検するのは現実的ではない時代に、その部品をまとめて取ってくる「入り口」のツールが安全かどうかは、開発現場全体の安全に直結します。pnpmに限らず、npmやyarnを含めたパッケージ管理ツールは、これからも攻撃者が真っ先に狙う場所であり続けます。手元のツールを最新に保つ習慣が、いちばん確実な守りになります。

参照元

• ▸ NVD - CVE-2026-55698 詳細
• ▸ NVD - CVE-2026-50016 詳細
• ▸ pnpm公式アドバイザリ - GHSA-w466-c33r-3gjp（CVE-2026-55698）
• ▸ pnpm公式アドバイザリ - GHSA-hwx4-2j3j-g496（CVE-2026-50016）
• ▸ pnpm - 公開済みセキュリティアドバイザリ一覧
• ▸ pnpm公式 - Mitigating supply chain attacks
• ▸ Socket - pnpm 11 Adds New Supply Chain Protection Defaults