セキュリティ研究者らが、npmのTrusted Publishingに存在する弱点を発見しました。この弱点を突かれると、攻撃者はメンテナーの認証情報を盗まなくても、悪意あるリリースを公開できてしまう可能性があります。
研究者らによると、「SlugFest」と名付けられたこの問題は、累計ダウンロード数が1,000万回を超え、月間ダウンロード数も100万回以上に上る1,500以上のパッケージに影響しました。
この脆弱性は、npmが公開権限をGitHubリポジトリと関連付ける方法に起因します。リポジトリが最初のTrusted Publishを完了するまで、npmは恒久的な数値ID（識別子）ではなく、人間が読める「owner/repository」形式のアドレス、いわゆるスラッグ（slug）に依存していました。
リポジトリの名前変更、移管、削除によってこのアドレスが再び取得可能になると、攻撃者はそれを再取得し、関連するnpmパッケージの公開権限を引き継げる可能性があります。
開示情報によると、Bloomは2026年6月6日にこの問題を報告し、GitHubは6月9日に問題を確認しました。10月2日に発表された緩和策では、未使用のTrusted Publishing設定が自動的に失効する仕組みが導入されました。最初の報告から約4か月後の対応です。github
Trusted Publishingは、長期間有効な自動化用シークレットを、OpenID Connect（OIDC）で取得する短期間有効な認証情報に置き換える仕組みです。GitHub Actionsのワークフローが ID トークンを要求し、それをnpmに渡して公開権限と交換します。
弱点は、最初の信頼設定の段階で生じていました。Bloomによると、npmはリポジトリのスラッグ、ワークフローのファイル名、任意の環境名を保存していました。
しかし、最初の公開が成功するまでは、この設定をGitHubの不変のリポジトリ識別子およびオーナー識別子に紐付けていませんでした。
攻撃者は、放棄された信頼済みスラッグと同じ名前でリポジトリを作成し、想定されるファイル名のワークフローを追加できます。すると、GitHubは攻撃者のリポジトリを示すOIDCトークンを発行します。このトークンには、新しい数値IDも含まれています。
npmは当初、数値IDが確立されていない状態でスラッグとワークフローの一致のみを確認していたため、このやり取りによって有効な公開用認証情報が返される可能性がありました。
Bloomは、研究者が管理するパッケージと、別々の組織に属するリポジトリを使って、この攻撃を実証しました。スラッグを共有していたため、正規のメンテナーのnpmアカウントやGitHubアカウントを侵害しなくても、公開が可能でした。
悪意あるリリースは、パッケージの見慣れた名前を保ったまま、既存ユーザーに届く恐れがあります。ライフサイクルスクリプトが有効な環境では、インストールスクリプトによって攻撃者が制御するコードが実行される可能性もあります。
署名の確認だけを行い、想定されるソースリポジトリを検証しないプロビナンス（来歴）チェックでは、こうした所有権の変更を見逃す可能性もあります。
Bloomの企業環境での観測によると、自律型コーディングツールがこのリスクを拡大させているとみられます。研究者らは、一般的なエンドポイントでエージェントが直接インストールするパッケージは月あたり約70個、開発者のマシンでは約350個に増えると報告しています。これらの数値には、間接的に取り込まれる依存関係は含まれていません。
そのため、エージェントが依存関係を選択する場合、開発者が一つひとつパッケージを手動で選ばなくても、侵害されたリリースが拡散される可能性があります。
ただし、この研究が示しているのは、あくまで悪用の可能性と管理された環境での実証であり、特定されたすべてのパッケージで実際に悪意ある乗っ取りが確認されたわけではありません。
GitHubの緩和策では、検証されていない設定は48時間で失効します。最初の公開が成功すると設定は検証済みとなり、失効の対象から外れます。リポジトリやプロジェクトのIDを変更する場合は、新たに信頼関係を構築する必要があります。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。チームで試してみる
翻訳元: https://cyberpress.org/npm-flaw-enables-takeovers/
