Bloom Securityの研究者らは、npmの「Trusted Publishing」機能に、認証情報を盗まなくても他人のパッケージの新バージョンを公開できてしまう欠陥があることを突き止めました。攻撃者に必要なのは、メンテナーが放置したGitHubリポジトリ名を登録することだけです。Bloomはこの方法で影響を受けるnpmパッケージを1,500件以上確認しており、npmを所有するGitHubは修正を提供したとしています。
影響を受けたパッケージのダウンロード数は合計1,000万回超、月間でも100万回を超えます。1パッケージあたりの月間ダウンロード数は平均で数百回にとどまりますが、乗っ取りには1パッケージで十分です。悪意あるバージョンにpostinstallスクリプトを仕込めば、そのアップデートをインストールしたすべてのマシンで、npmが自動的にコードを実行してしまいます。
攻撃の仕組み
Trusted Publishingは2025年7月に一般提供が始まった機能で、長期間有効な公開用トークンに代わるものです。メンテナーは、パッケージを公開できるGitHubリポジトリとワークフローファイルをnpmに登録します。該当のワークフローが実行されると、GitHubが署名付きのIDトークンを発行し、npmはそれを数分で失効する公開用の認証情報と交換します。
npmはリポジトリを名前、つまりGitHubが「スラッグ」と呼ぶowner/repo形式の文字列で記録していました。一方、GitHubはすべてのリポジトリとオーナーに、名称変更や移管後も変わらない恒久的な数値IDを割り当てており、トークンにも両方のIDが含まれます。しかしnpmは、これらを検証していませんでした。メンテナーが紐付け済みのリポジトリの名称を変更・移管・削除した場合、あるいはオーナーアカウントの名称を変更・削除した場合、元のスラッグは誰でも使える状態になります。攻撃者はその名前でリポジトリを作成し、ファイル名が一致するワークフローファイルを追加するだけで、自分のものではないパッケージの公開用認証情報を受け取れました。
Bloomは、研究者自身が管理するパッケージとリポジトリを使い、空いたスラッグを取得した別組織のリポジトリから公開する形で、攻撃を最初から最後まで実証しました。この方法で公開されたリリースには、攻撃者のリポジトリを示す有効なプロビナンス証明（署名付きのビルド記録）も付与されます。
GitHubは、オーナーアカウントの名称変更や削除の前の1週間に100回を超えてクローンされたリポジトリの名前を使用不可にしており、これで一部のパッケージは守られます。「この点は考慮に入れています。脆弱と判断したものはすべて、取得可能なスラッグに関するものでした」と、Bloom Securityのセキュリティ研究者Golan Myers氏は述べています。
GitHubの対応
Bloomは6月6日にGitHubのバグバウンティプログラム（HackerOne）を通じてこの問題を報告し、GitHubは6月9日にこれを確認しました。Bloomによると、最後に返信を受け取ったのは7月8日で、その後はHackerOneへの調停依頼を含む6回のフォローアップにも応答がなかったということです。
GitHubの広報担当者はHelp Net Securityに対し、次のように述べました。「この問題はバグバウンティプログラムを通じて把握し、報告内容の検証と修正の提供を進めました。未検証のTrusted Publishing設定は、作成から48時間で失効し、公開の認可には使えなくなりました。これにより、所有者が変わるリポジトリ名やプロジェクト名を信頼するリスクが抑えられます」
GitHubは10月2日にこの変更を発表しました。npmのドキュメントによると、設定は最初の公開に成功した時点で、リポジトリの「不変のID」に紐付けられます。ただしGitHubの声明は、変更前に公開実績のある設定にも遡って紐付けが適用されたかどうかには触れていません。Myers氏は、この欠陥が実際に悪用されたかどうかは不明だと述べました。
AIエージェントが拡大させる影響
Bloomは、AIコーディングエージェントの普及で、この種の欠陥の影響がより広範に及ぶと指摘しています。数十の組織から得たテレメトリに基づく推計では、一般的なエンドポイント上のエージェントは月に約70個のパッケージをインストールし、開発者のマシンでは依存関係を除いて350個近くに達します。しかも、こうしたインストールは、パッケージやそのメンテナーを確認しないまま行われるのが通常です。
「AIエージェントによって状況は一変しています。『開発者向けソフトウェア』を利用するのは、もはや開発者だけではありません。そのため、この種の問題は従来の認識とは異なり、すべてのユーザーに影響します」とMyers氏は述べています。
確認すべきこと
Trusted Publishingを使ってパッケージを管理している場合は、npm trust listを実行し、一覧に表示された各リポジトリが、今も自分の管理下にあるものを指していることを確認してください。名称変更や移管を行ったリポジトリを指している紐付けは、削除して作り直す必要があります。また、リポジトリを削除する際は、先に紐付けを解除してください。
Bloomは影響を受けたパッケージ名を公開していないため、npmパッケージの利用者は一覧と照合して確認することはできません。代わりに、パッケージのプロビナンス証明に、そのプロジェクトが本来由来するはずのリポジトリが記載されているかを検証できます。
Bloomによると、npmのGitLab向けTrusted Publishing連携にも同じ弱点があります。
翻訳元: https://www.helpnetsecurity.com/2026/10/13/slugfest-npm-trusted-publishing-flaw/
