自己増殖型サプライチェーン攻撃Shai-Hulud 2.0 （Sha1-Hulud 2.0）が猛威をふるっています。
2025年11月24日時点で影響を受けたnpmパッケージは約800個、GitHubリポジトリは25,000以上に及んでいます。
この中には、ZapierやPostmanなど有名なものも含まれています。最近、これらのパッケージをインストールした方は要注意！
どんなウイルスか、何をすればよいか、本記事ではこの点をお伝えします。
既に色々な記事があり、そちらも非常に役立ちます。ただ、やや専門的な説明が多すぎるような気もします。
そこで、本記事は確認方法と対策重視でお伝えしますね。
Shai-Hulud 2.0とは？どんなウイルス？
ひとことでいえば、最悪の『自己増殖型』サプライチェーン攻撃です。
-
感染経路：
npm installを実行した瞬間に感染し、PC内の認証トークン（AWSやGitHubの合鍵）を盗み出す。 -
挙動： 盗んだ権限で勝手にリポジトリを作成して、ローカル上の機密情報をばら撒く。GitHub Actionsに裏口（Runner）を設置。
-
リスク： 自分のPCが踏み台になり、チームメンバーや他のプロジェクトへ無限に感染を広げてしまう。
-
さらに深刻なリスク： 認証情報の窃取に失敗した場合、マルウェアはホームディレクトリ全体を破壊しようとする。
今すぐやるべきチェック
今感染しているかどうかをチェックする方法をご紹介します。
ライブラリチェック
すでに影響を受けたことが報告されているライブラリについては、下記記事の「Impacted Packages」より確認できます。ZapierやPostmanなど有名なものが含まれています。
GitHubの「不審な動き」を確認
すでに被害に遭っていないかチェックします。
-
リポジトリ一覧： 身に覚えのないリポジトリが作られていないか？
-
Actions（裏口）の確認：
-
主要なリポジトリの
Settings>Actions>Runnersを確認。 -
知らない「Self-hosted runner」が登録されていたら即削除。（ここがバックドアになり、PCを外部から遠隔操作されます）
-
もし異常があれば「トークン」を全変更
上記で怪しい点が見つかった場合、PC内の「合鍵」がコピーされている可能性があります。
GitHubのアクセストークン（PAT）、AWS/GCPのクレデンシャル、npmのトークンなどを無効化・再発行します。
PC内の「感染源」を掃除（キャッシュクリア）
PC内に汚染されたライブラリが保存されている可能性があるため、履歴をリセットします。
-
npmの場合：
npm cache clean --force -
Bunの場合：
bun pm cache rm
デメリットとしては、キャッシュがなくなるため、次回インストールする際に時間がかかります。
今後の対策
今後の対策についてもまとめます。
怪しいライブラリを見極める
新しくライブラリを入れる時は、以下の3点をチェック。
-
名前： 有名なものと似ていないか？
-
公開日： 昨日や今日リリースされたばかりではないか？
-
DL数： 有名なはずなのに、週間ダウンロード数が極端に少なくないか？
package.jsonの中身をチェックする
インストールしようとしているライブラリの package.json を見て、scripts 欄に以下のような記述があったら危険です。
|
1 2 3 |
"scripts": { "preinstall": "node setup_bun.js" } |
または
|
1 2 3 |
"scripts": { "preinstall": "node bun_environment.js" } |
ファイル名は変わる可能性もありますが、「preinstall（インストール前）で、Bunのセットアップと思われるJSファイルを実行しようとしている」 点が特徴です。
アカウント防御の強化
今後のためにも、以下の設定の見直しをおすすめします。
2FAとパスキーの設定
まだの方は、2FA（2要素認証）とパスキーを有効にすることでセキュリティレベルが向上します。
→ GitHub: Settings > Password and authentication
トークンの権限の見直し
Personal Access Tokenで不要な権限を持つものがないかチェックして、リポジトリ作成権限を持つ不要なトークンがあれば削除・または権限を絞るなどします。
→ GitHub: Settings > Developer Settings > Personal access tokens
OAuth連携アプリの見直し
使っていないアプリや、信頼できないアプリとの連携は削除しましょう。
→ GitHub: Settings > Applications > Authorized OAuth Apps
「不要なアクセス権限を与えない」というのが非常に大事です。
GitHub側の対応
GitHubは11月26日から、トークンの無効化や悪意あるリポジトリの非公開化など対応を進めています。
ですが既に盗まれた認証情報はGitHub側では完全には把握できませんし、PC内のキャッシュも自動削除されません。そのため、自分での対策が必須です。
まとめ
今回の攻撃では、Bunが使われています。こちら、npmの代替として利用できる高機能なランタイムです。
これによって、こういった攻撃が容易になったと考えられます。
Bun自体が悪いわけではありません。
高性能なツールができたことで、攻撃者にとっても使いやすくなってしまった、ということかと思います。
なお今回の攻撃は、OWASP Top 10 の「Software Supply Chain Failures」に該当すると思われます。
ここからまた、色々とこういった攻撃が繰り広げられていきそうですよね。ぜひ、セキュリティ意識高めていきましょう。
