npm「Trusted Publishing」に公開権限乗っ取りの欠陥、1,500超のパッケージに影響リスク―GitHubが初回公開を48時間に制限

GitHubは2026年10月2日、npmのTrusted Publishing（信頼された公開元）設定について、新規作成から48時間以内に最初の公開が成功しなかった場合、設定を失効させる変更を発表しました。セキュリティ企業Bloom Securityが10月13日に公表した調査によると、従来の認証処理には、GitHubリポジトリの名前が変更・削除された際に第三者が古い名前を取得し、正規のnpmパッケージへ新しいバージョンを公開できる問題がありました。

Bloom Securityはこの問題を「SlugFest」と命名し、1,500件を超えるnpmパッケージが攻撃可能な状態にあったと報告しています。対象としたパッケージのダウンロード数は累計1,000万回を超えます。ただし、これは実際に乗っ取られたパッケージ数やマルウェアのダウンロード数ではありません。同社は自ら管理する環境で問題を実証しており、第三者による実攻撃が確認されたという発表ではありません。

npm Trusted Publishingの仕様変更・脆弱性のサマリー

• GitHubは2026年10月2日、未検証のnpm Trusted Publishing設定を作成から48時間で失効させる変更を公開しました。
• 48時間以内に初回の公開が成功すると設定が検証され、リポジトリの変更できない識別情報と結び付けられ、失効期限の対象から外れます。
• 48時間経過で失効した設定では公開できず、利用を続けるには新たなTrusted Publishing設定を作成する必要があります。
• リポジトリやプロジェクトの識別情報が変わる場合も、改めて信頼関係を設定します。通常の設定編集だけでは期限は延長されません。
• Bloom Securityは、公開元の識別にGitHubリポジトリの可変な名前（owner/repo）を使用していた問題「SlugFest」を2026年10月13日に公表しました。
• 同社の調査で攻撃可能と判断されたnpmパッケージは1,500件超、累計ダウンロード数は1,000万回超、月間では100万回超でした。
• npmはGitHub Actionsのissue_commentイベントで発行されたTrusted Publishing用トークンを拒否するよう変更しました。既存のpull_request_target制限も継続します。

Trusted Publishingとは―長期保存する公開用トークンを不要にする仕組み

npmのTrusted Publishingは、GitHub ActionsなどのCI/CD環境からパッケージを公開する際、OpenID Connect（OIDC）を使って短期間だけ有効な認証情報を発行する仕組みです。従来のように公開権限のある長期トークンをワークフロー内に保存する必要がなく、認証情報の漏えいリスクを減らせます。

パッケージ管理者は、公開を許可するGitHubの組織・リポジトリ名、ワークフローのファイル名などをnpm側に登録します。公開処理の際はワークフローから送られたOIDCトークンを照合して、公開を許可するか判断します。

今回の問題はOIDCという認証技術自体の欠陥ではなく、npm側が初回公開前の信頼設定で、公開元リポジトリをどの情報に基づいて識別していたかという実装上の問題です。

「SlugFest」で何が問題になったのか

GitHubのリポジトリには、人が読めるowner/repository形式の名前と、名前が変更されても変わらない固有のIDがあります。

Bloom Securityによると、問題のあったTrusted Publishing設定では、最初の公開が成功するまで、主にリポジトリ名とワークフローファイル名が照合されていました。この段階では、トークンに含まれるリポジトリ固有のIDとの結び付けがまだ完了していませんでした。

そのため、管理者がGitHubリポジトリを改名・移管・削除するなどして旧名が再利用可能になると、第三者がその名前を取得し、正規の公開元に見せかけてパッケージの公開権限を得る恐れがありました。正規のnpmアカウントやGitHubアカウントを直接侵害したり、管理者の公開用パスワードを盗んだりする必要がない点が特徴です。

研究者は自ら管理するnpmパッケージとGitHubリポジトリを使い、別の組織が所有するリポジトリから同一パッケージの新バージョンを公開できることを実証しました。

不正な公開が行われた場合、パッケージを更新した開発環境やCI/CD環境へ悪意あるコードが取り込まれ、ソフトウェアサプライチェーン攻撃につながる恐れがあります。署名付きの来歴情報（provenance）が存在するだけでは、公開元が本来の管理者のリポジトリかどうかを十分に判断できない場合があると、研究者は指摘しています。

GitHubが導入した48時間ルール―すべての設定が2日で失効するわけではない

GitHubの10月2日付Changelogとnpm公式ドキュメントによると、変更の対象は初回公開が済んでいない、新規作成された信頼設定です。

失効した設定は管理画面上に表示されても、公開を許可する機能は失われます。他の有効なTrusted Publishing設定には影響しません。

また、GitHub Actionsのissue_commentイベントを契機としたOIDCトークンは新たに拒否されます。pull_request_targetイベントの制限も継続され、公式案内ではpush、release、workflow_dispatchなどのイベントへの移行が例示されています。これらのイベントを選ぶ場合も、ワークフローの実行権限と公開権限の設定は別途点検する必要があります。

1,500超のパッケージと累計1,000万ダウンロードは「確認された被害」ではない

Bloom Securityはnpmのパッケージと公開元の設定を調査し、第三者が取得できるリポジトリ名との組み合わせなどから、1,500件を超えるパッケージが問題の条件に該当すると判断しました。同社は対象の一覧を公開していません。

累計1,000万回超、月間100万回超という数字は、同社が特定したパッケージのダウンロード規模を示すものであり、不正なバージョンの配信実績ではありません。

同社による検証と実際の攻撃を混同してはなりません。今回の報告は、パッケージの公開権限を第三者が引き継げる危険が存在したことと、それに対するプラットフォーム側の対策が実装されたことを示しています。

npmパッケージの公開担当者が確認したいこと

npm公式ドキュメントは、Trusted Publishingの設定を作成した場合、2日以内に初回の公開を成功させ、公開元を検証するよう案内しています。公開担当者は次の運用を点検できます。

1. npmパッケージのTrusted Publishing設定を開き、未検証・失効した設定や、旧リポジトリ名が残っていないか確認する。
2. 失効している設定は作成し直し、48時間以内に初回公開を完了させる。リポジトリの改名・移管後も旧設定を放置しない。
3. GitHub Actionsの公開用ワークフローがissue_commentやpull_request_targetを契機に実行されていないかを確認し、必要に応じて公開トリガーを見直す。
4. 不審なバージョン公開がないか、npmの公開履歴、GitHub Actionsの実行履歴、provenanceの公開元を突き合わせる。
5. 重要なパッケージは、npmが提供するStaged Publishingの承認工程や公開権限の最小化を検討する。

npm公式ドキュメントでは、可能な環境でTrusted Publishingを継続利用し、不要な長期アクセストークンを無効化することも推奨しています。今回の欠陥だけを理由に長期トークン方式へ戻すことは、別の認証情報漏えいリスクを増やす可能性があります。

依存パッケージを利用する側では、SBOMによるソフトウェア構成・依存関係の把握が影響範囲を絞り込む一助になります。また、正規パッケージの更新経路が悪用された過去事例については、npmのサプライチェーン攻撃を整理した記事でも取り上げています。

出典

• Unvalidated npm trusted publishing configurations now expire（2026年10月2日） – GitHub Changelog
• SlugFest: Millions of AI Agents Install npm Packages Exposed to Malicious Takeover through GitHub（2026年10月13日） – Bloom Security
• Trusted publishing for npm packages – npm公式ドキュメント
• Multiple trusted publishing configurations for npm（2026年9月3日） – GitHub Changelog