pnpmの複数アドバイザリを受け、開発端末、CI、lockfile、リポジトリ設定、トークンをどう確認するかを解説。公式情報に基づき、対象バージョン確認、更新判断、証跡保全、再ビルド範囲、監査ログ確認まで、情シスと開発者向けに初動対応を整理します。
何が起きたか
2026年6月26日から27日にかけて、GitHub Advisory Databaseで pnpm に関する複数のアドバイザリが公開されました。確認できる範囲では、CVE-2026-55698、CVE-2026-55700、CVE-2026-55699、CVE-2026-55697、CVE-2026-55487 などが含まれ、GitHub Advisory上ではHighまたはMediumとして扱われています。
pnpmは、JavaScript/TypeScript開発で依存関係を解決し、lockfileやワークスペース設定、CIのインストール処理に深く関わるパッケージマネージャーです。そのため、単に「開発ツールを更新する」だけでなく、どの端末・CI・リポジトリ・lockfile・トークンに影響し得るかを確認する必要があります。
この記事では、攻撃再現や悪用手順には触れず、開発者、SRE、情シス、SaaS管理者が公式情報を見ながら初動判断を進めるための確認手順に絞って整理します。
本記事は、GitHub Advisory Database、pnpm公式リリース、NVDで確認できる情報をもとにしています。CISA KEV JSONも確認しましたが、本記事執筆時点で今回扱うpnpmアドバイザリがKEVへ登録されていることは確認していません。悪用状況や被害規模は断定しません。
影響を受ける可能性がある組織・担当者
| 読者 | まず見るもの | 見落とすと起きること |
|---|---|---|
| 開発者 | ローカルのpnpmバージョン、対象リポジトリ、lockfile、ワークスペース設定 | 古いpnpmや信頼できない設定を使ったまま開発を続ける |
| SRE・DevOps | CIランナー、コンテナビルド、キャッシュ、パッケージ公開フロー | 古いpnpmで再ビルドされ、影響範囲の切り分けが難しくなる |
| 情シス・SOC | 開発端末台帳、EDR、プロキシ、DNS、IdPログ | 開発端末上の異常や認証情報露出の可能性を通常作業として見落とす |
| SaaS管理者 | GitHub、npm、クラウド、CI/CDのトークンと監査ログ | 長期トークンや広い権限が残り、後続アクセスに使われる |
特に、外部リポジトリを頻繁にcloneする開発者、CIでリポジトリ管理下の設定をそのまま使う環境、パッケージ公開用トークンやクラウド資格情報をCIへ持たせている環境では、確認範囲を広めに取るべきです。
なぜ重要か
パッケージマネージャーは、依存関係をインストールするだけの補助ツールではありません。実務では、次のような高い権限や重要な証跡と接点があります。
package.json、lockfile、ワークスペース設定を読み、依存関係の解決に影響する。- CI/CDのビルド、テスト、リリース、パッケージ公開に使われる。
- 開発端末やCIに保存されたGitHub token、npm token、クラウド資格情報と同じ実行環境で動く。
- コンテナイメージ、キャッシュ、社内テンプレートに古い状態が残る場合がある。
- 依存関係の変更履歴や再現性を説明するうえで、lockfileが重要な証跡になる。
今回のように複数のアドバイザリが短期間で公開された場合は、個々のCVEだけを追うよりも、パッケージマネージャー更新、設定ファイル確認、CI再ビルド、トークン棚卸しを一つの初動として扱う方が実務では安全です。
まず確認すべきこと
1. 自社で使っているpnpmの版を固定する
packageManager、Corepack設定、CIイメージ、開発端末の標準手順を確認する。- pnpm 10系と11系を分けて、対象となるバージョン範囲を公式アドバイザリで確認する。
- CIのベースイメージ、キャッシュ、社内テンプレート、古いプロジェクトに別バージョンが残っていないか確認する。
- 「開発端末だけ」「CIだけ」「一部リポジトリだけ」といった例外を記録する。
pnpm公式リリースでは、10系の 10.34.2、10.34.3、10.34.4 にセキュリティ修正が含まれています。最終的な適用先は、組織で採用しているメジャーバージョン、テスト結果、公式リリースノートを照合して決めてください。
2. lockfileとリポジトリ管理下設定を確認する
pnpm-lock.yaml、pnpm-workspace.yaml、プロジェクト配下の設定ファイルを確認対象に入れる。- 外部から取り込んだリポジトリ、fork、テンプレート、サンプルプロジェクトを優先して見る。
- lockfileがいつ、誰のPRで、どのCIで更新されたかを履歴として確認する。
- 設定ファイルにCIトークンやレジストリ情報が直接埋め込まれていないかを確認する。
ここで重要なのは、設定値の「怪しさ」を目視だけで判断しないことです。公式アドバイザリが示す影響範囲と、自社のリポジトリ運用、レビュー履歴、CI実行履歴を突き合わせます。
3. CI・キャッシュ・コンテナを再確認する
- CIで使うpnpmの取得方法を確認し、固定値、Corepack、コンテナイメージ、キャッシュのどこで版が決まるかを見る。
- 古いpnpmがキャッシュ、ビルドイメージ、開発者向けテンプレートに残っていないか確認する。
- 対象期間に作られた成果物、コンテナイメージ、パッケージ公開履歴を一覧化する。
- 更新後に再ビルドすべき成果物と、再ビルド不要と判断できる成果物を分ける。
CIは「自分の端末では更新済み」でも古いツールチェーンが残りやすい場所です。更新対象は開発端末だけでなく、CIランナー、Dockerfile、Dev Container、社内テンプレートまで広げます。
4. トークンと監査ログを見る
- GitHub PAT、GitHub App、Actions Secrets、npm token、クラウド資格情報を一覧化する。
- CI上で使う長期トークン、広い権限、個人所有のトークンを優先して見直す。
- npmやGitHubで、予期しないpublish、権限変更、workflow実行、secret変更がないか確認する。
- 不審点がある場合は、削除より先に証跡保全、失効、再発行、利用履歴確認をセットで進める。
推奨される初動対応
やること
- GitHub Advisory、pnpm公式リリース、NVDで対象バージョンと修正方針を確認する。
- 開発端末、CI、コンテナ、社内テンプレートで使っているpnpmの版を一覧化する。
- 10系を使う環境では、10.34.4以降への更新可否を優先確認する。
- 11系を使う環境では、各アドバイザリで示された修正済み版と公式リリースノートを照合する。
- lockfile、ワークスペース設定、リポジトリ管理下設定を確認し、対象期間の変更履歴を残す。
- CIキャッシュ、ビルドイメージ、成果物を更新後に再生成すべきか判断する。
- トークン露出の可能性が否定できない場合は、失効、再発行、監査ログ確認を行う。
やってはいけないこと
- アドバイザリの詳細をもとに、攻撃再現や検証用の悪性リポジトリを作らない。
- 「pnpmを更新した」だけで、CI、キャッシュ、lockfile、トークン確認を省略しない。
- 証跡を残さずにlockfileやCIログを消さない。
- 公式情報で確認できない悪用状況、被害規模、攻撃者名を断定しない。
- 端末やCIに残るsecretをチケットやチャットへ貼り付けない。
記録すべきこと
確認日時:
対象アドバイザリ:
対象プロジェクト:
pnpmの版:
10系 / 11系:
確認したlockfile:
確認したCI:
更新後の版:
再ビルド対象:
失効・再発行したトークン:
監査ログ確認結果:
未確認事項:
次回確認日:判断基準
| 優先度 | 条件 | 推奨対応 |
|---|---|---|
| 高 | CIまたは開発端末で影響範囲のpnpmを使っている | 更新、CI再実行、lockfile確認、トークン棚卸しを同時に進める |
| 高 | 外部リポジトリや未信頼のテンプレートを頻繁に扱う | リポジトリ管理下設定とlockfileのレビューを優先する |
| 高 | CIにnpm/GitHub/クラウドの長期トークンがある | トークン失効、再発行、監査ログ確認をインシデント初動として扱う |
| 中 | 対象有無が不明だが、古いCIイメージやキャッシュがある | 影響範囲を確定するまで再ビルドとキャッシュ更新を計画する |
| 低 | 公式情報と台帳で対象外が確認できる | 根拠、確認日時、再確認条件を残してクローズする |
対応する実務集記事
実務でそのまま確認する場合は、パッケージマネージャー緊急更新チェックリスト を使ってください。pnpmに限らず、npm、yarn、Corepack、CIイメージ、lockfile、パッケージ公開トークンの確認観点を一つの表にまとめています。
より広い開発者環境の棚卸しには、開発ツール・OSSサプライチェーン確認チェックリスト、トークン漏えい疑いがある場合は GitHubトークン漏えい対応テンプレート へ進んでください。
関連するCyberLens内部リンク
- パッケージマネージャー緊急更新チェックリスト：今回の実務確認ページ。
- 開発ツール・OSSサプライチェーン確認チェックリスト：拡張機能、CI、トークン、端末まで広げて確認する。
- GitHub secret leak対応チェックリスト：トークン露出が疑われる場合の確認手順。
- GitHubトークン漏えい対応テンプレート：報告、失効、復旧、再発防止を進める。
- SBOMとOSVで学ぶ依存関係確認：依存関係確認の学習ページ。
- Supply Chain Risk Management：サプライチェーンリスク管理の用語。
- SBOM：ソフトウェア部品表の基礎。
公式情報の確認先
- GitHub Advisory Database: GHSA-w466-c33r-3gjp — CVE-2026-55698、CVSS、影響範囲を確認できる。
- GitHub Advisory Database: GHSA-v23m-ccfg-pq9h — CVE-2026-55700、CVSS、影響範囲を確認できる。
- GitHub Advisory Database: GHSA-qrv3-253h-g69c — 10.34.4に関係する修正の根拠として確認した。
- pnpm release: pnpm 10.34.4 — 10系の追加セキュリティ修正を確認できる。
- pnpm release: pnpm 10.34.2 — リポジトリ管理下設定の扱いに関するセキュリティ修正を確認できる。
- NVD: CVE-2026-55698 — NVD上のCVSSと説明を確認できる。
- NVD: CVE-2026-55700 — NVD上のCVSSと説明を確認できる。
まとめ
pnpmの複数アドバイザリは、パッケージマネージャーを「開発者の手元のツール」ではなく、CI、lockfile、リポジトリ設定、トークン運用を含む開発基盤として扱う必要があることを示しています。
まずは、公式情報を確認し、対象版の有無、CIと開発端末、lockfile、トークン、監査ログを同じ時系列で整理してください。手順化する場合は、パッケージマネージャー緊急更新チェックリスト から始めるのが最短です。
