npm(Node.jsのパッケージを配る仕組み)のTrusted Publishing(信頼された公開)に、他人のパッケージを乗っ取れる弱点があったと、セキュリティ会社のBloom Securityが報告しました。研究者は「Slugfest」と呼んでいます。1,500以上のパッケージが影響を受け得る状態でした。
npmを運営するGitHubは、すでに修正を出しています。この記事は、Help Net Securityの報道とGitHubの変更履歴をもとに、仕組みと、公開する会社・使う会社それぞれの点検を整理します。攻撃の手順は扱いません。
Trusted Publishingとは何か
従来、npmにパッケージを公開するには、長期間有効な公開用トークン(合い鍵のようなもの)を使いました。盗まれると、他人が公開できてしまいます。
Trusted Publishingは、このトークンをなくす仕組みです。2025年7月に一般提供が始まりました。npmのドキュメントは、OpenID Connect(OIDC)を使い、公開のたびに、そのワークフローに固有の署名付きの短期トークンを使うと説明しています。
流れは次のとおりです。
- 公開する人が、npmに「このGitHubのリポジトリと、このワークフローのファイルだけが公開してよい」と登録する
- そのワークフローが動くと、GitHubが署名付きの身元トークンを発行する
- npmがそれを、数分で切れる公開用の資格情報と交換する
弱点の考え方: 名前だけで信頼していた
Help Net Securityの報道によると、npmは結びつけたリポジトリを「slug」、つまりowner/repoという名前の文字列で記録していました。
一方、GitHubはリポジトリと所有者のそれぞれに、名前変更や移管をしても変わらない数値IDを割り当て、身元トークンにも入れています。npmは、この数値IDを検証していませんでした。
そのため、次のようなときに問題が起きます。
- 結びつけたリポジトリの名前を変えた、移管した、削除した
- 所有者のアカウント名を変えた、アカウントを削除した
こうすると、元の名前(slug)が空きます。別の人がその名前でリポジトリを作り、一致する名前のワークフローを置けば、自分のものでないパッケージの公開用の資格情報を受け取れてしまいます。トークンを盗む必要はありません。
この方法で公開された版にも、正当に見える来歴(provenance、誰がどこで作ったかの署名付きの記録)が付きます。ただし、来歴に書かれるのは攻撃者側のリポジトリ名です。
GitHubは、100回を超えてクローンされたリポジトリの名前を、所有者アカウントの名前変更・削除の前の1週間に引退させています。これで守られていたパッケージもあります。
影響の大きさと、経緯
Bloomは、この方法で乗っ取り得るパッケージを1,500超と数えています。合計のダウンロードは1,000万回超、月100万回超です。1つ当たりは小さくても、1つ乗っ取られれば足ります。悪意ある版には、インストール時に自動で動くpostinstallスクリプトを仕込めます。
報道が伝える経緯は次のとおりです。
| 日付 |
出来事 |
| 2026年6月6日 |
BloomがHackerOne経由でGitHubに報告 |
| 6月9日 |
GitHubが報告を確認 |
| 7月8日 |
Bloomが受け取った最後の返信。その後の問い合わせに返事がなかったと、Bloomは述べている |
| 10月2日 |
GitHubが修正を発表 |
GitHubはHelp Net Securityに、報告を受けて確認し、修正を出したと答えています。Bloomの研究者は、実際に悪用された例があるかは分からないと述べています。影響を受けたパッケージの名前は公表されていません。
GitHubの修正の中身
GitHubの変更履歴(2026年10月2日)の内容は次の4点です。
- 検証されていないTrusted Publishingの設定は、作成から48時間で期限切れになり、公開を認可できなくなります
- 最初の公開に成功すると、設定は検証済みになり、期限切れの対象から外れます
- リポジトリやプロジェクトの指定を変えると、新しい信頼関係として、48時間の検証の窓が改めて必要です。通常の編集では期限は延びません
- 期限切れの設定は設定画面に残りますが、公開は認可しません。作り直すと新しい48時間が始まります
GitHubの変更履歴が説明する、検証されていない設定の48時間での期限切れ出典: GitHub Changelog(引用)
npmのドキュメントも、最初の公開の成功で、設定がリポジトリの「不変の身元」に結びつくと説明しています。
もう1点あります。npmは、GitHub Actionsのissue_commentイベントからのTrusted Publishingトークンも拒否するようになりました。すでにあるpull_request_targetの制限に加えたものです。影響がある場合は、push、release、workflow_dispatchなど許可されたイベントに公開を移します。
影響する会社・しない会社
- 影響する: npmにパッケージを公開していて、Trusted Publishingを使っている会社(自社の製品、社内向け、委託先が公開するものを含む)。結びつけたリポジトリや所有者の名前を変えたり、移管・削除したりした設定が残っていれば、特に確認が要ります
- 影響する: issue_commentのイベントでパッケージを公開するワークフローを組んでいる会社。公開が拒否されるようになりました
- 影響する(間接的に): npmのパッケージを依存として使っている会社。ほぼ全てのWeb開発が当てはまります。乗っ取られたパッケージの版を取り込めば、インストールした環境でpostinstallが動くおそれがあります
- 影響しない: npmにパッケージを公開しておらず、Trusted Publishingを設定していない会社(公開用の資格情報が別の方法のため、この弱点の対象ではありません)
- 影響しない: npmを開発に使っていない会社
情シスが今日やること
公開する側(自社やチームがnpmに公開している場合)
- npmの管理画面か、npm trust listのコマンドで、Trusted Publishingの設定の一覧を出します(報道がBloomの案内として伝える方法です)
- 一覧の各リポジトリが、今も存在して自社のものかを確かめます。名前変更・移管・削除をしたものは、設定を削除して作り直します
- 期限切れの設定がないかを見ます。あれば作り直し、最初の公開を成功させて検証済みにします
- 今後、リポジトリや所有者の名前を変える前に、先にnpm側の結びつけを外す決まりを作ります
- 公開のワークフローが、issue_commentのイベントを使っていないかを確かめます。使っていれば、pushやreleaseなどへ移します
使う側(依存パッケージを取り込んでいる場合)
- 依存のバージョンを、ロックファイル(package-lock.jsonなど)で固定します。意図しない更新を取り込まないためです
- 新しい版は、公開された直後に自動で取り込まず、少し待ってから入れる運用を検討します。CIの更新ツールの設定で決められます
- CIで、インストール時のスクリプトを動かさない設定(ignore-scripts)の使える範囲を確認します。動かす必要があるパッケージは、一覧にして把握します
- 重要なパッケージは、来歴が、そのプロジェクトが本来あるはずのリポジトリを指しているかを確かめます。Bloomの案内として、報道が伝えています
- 開発者の端末やCIが、鍵やクラウドの認証情報を持ちすぎていないかを見直します。悪意ある版が動いても、被害を小さくするためです
関連の記事として、GitHubの346リポジトリに偽の監査ワークフロー、クラウドの鍵を窃取も、開発のサプライチェーンの話です。
書かれていないこと
- Bloom Securityの調査レポートの原文。探しましたが見つからず、この記事は報道を通して伝えています
- 実際に悪用された例があるか(Bloomの研究者は、分からないと述べています)
- 影響を受けたパッケージの名前(公表されていません)
- 変更前に検証済みだった設定を、さかのぼって結びつけたかどうか
- GitLabの連携についてのnpmやGitHubの対応(Bloomが同じ弱点を述べているとの報道のみ)
2026年10月13日時点の内容です。
