TITLE

npmサプライチェーン攻撃「Shai-Hulud」再来——keyv侵害に見る『見えない実行スイッチ』への対策

投稿日:2026.08.05

CATEGORY

  • Web開発
npmサプライチェーン攻撃「Shai-Hulud」再来——keyv侵害に見る『見えない実行スイッチ』への対策

今朝もいつも通り npm install を叩いた——その一行が、認証情報を盗み出すマルウェアの起動スイッチだったとしたら。2026年8月4日、npm の人気パッケージ keyv・cacheable ファミリーなど70以上のパッケージが「Shai-Hulud」と名付けられた攻撃キャンペーンで乗っ取られ、npm install を実行しただけで自動的に発火する認証情報窃取マルウェアが仕込まれていたことが発覚しました。起点になったのは preinstall という、npm がパッケージのインストール時に自動実行するフックの仕組みです。

2026年8月4日に何が起きたか——keyv・cacheableファミリーが乗っ取られた

攻撃者は、keyv・cacheable ファミリーのメンテナである npm ユーザー jaredwray のアカウント権限を奪い、悪性コードを注入しました。影響を受けた主要パッケージには keyv@6.0.0、cacheable-request@13.0.20、file-entry-cache@11.1.6、cache-manager@7.2.10、crawlee@3.17.1-beta.80 などがあり、70パッケージ以上に及びます。Aikido Security の分析では、この攻撃はワーム的な自動拡散の挙動を持ち、434以上のパッケージに感染、月間合計20億以上のインストール数に影響したとされています。侵害パッケージ数や影響範囲は情報源・調査時点によって数字に幅があり(数百から始まり、その後さらに拡大したという報道もあります)、本稿執筆時点でも進行中の事案として扱うべき状況です。

この攻撃キャンペーンには「Shai-Hulud」という名前が付けられました。「ここに戻ってきた」という意味を込めた命名で、2026年内では同名キャンペーンとして2回目の出現になります。

「見えない実行スイッチ」——preinstallフックはなぜここまで危険なのか

この攻撃が厄介なのは、被害者が何も特別な操作をしていない点にあります。開発者やCIパイプラインが行うのは、いつも通りの npm install だけです。npm にはパッケージのインストール前後に任意のスクリプトを自動実行する「ライフサイクルフック」という仕組みがあり、その一つである preinstallnpm install を実行した瞬間、確認なしに発火します。攻撃者は package.json に "preinstall": "node setup.mjs" という1行を追加するだけで、この仕組みを「見えない実行スイッチ」に変えました。

攻撃の流れを図にまとめました。

Shai-Hulud攻撃の4段フロー図。STEP1侵害(アカウント乗っ取り)→STEP2発火(preinstallフックが自動発動)→STEP3窃取(認証情報を収集)→STEP4送信(C2サーバーへ送信)を1本の背骨に並べた図解

4段の攻撃フローと、盗まれるもの

最初の段階(Stage0・侵害)では、package.json に setup.mjs・Math_Symbol.js という悪性ファイルが追加され、preinstall スクリプトが仕込まれます。次の段階(Stage1・発火)では、npm install の実行と同時に発火した preinstall フックが setup.mjs を起動し、Bun ランタイムをダウンロード・実行します。3段目(Stage2・窃取)で、メインペイロードが実行され、端末内の認証情報・暗号資産ウォレット・SSH鍵・クラウド認証情報が根こそぎ収集されます。Aikido Security の分析では、窃取対象として npm トークン・GitHub トークン・AWS 認証情報・Kubernetes シークレット・Vault トークン・Stripe や Slack の API キー・秘密鍵ファイルが具体的に挙げられています。最後の段階(送信)で、収集された情報が C2サーバー(npm-cache.com)へ送信され、攻撃者の手に渡ります。

一つの npm install の裏で、依存関係の取得と資格情報の窃取が同時に走っていた——それがこの攻撃の実態です。

今すぐやるべきこと——影響範囲の確認とローテーション

まず確認すべきは、自社の package-lock.json・yarn.lock・pnpm-lock.yaml に、keyv・cacheable-request・file-entry-cache・cache-manager・crawlee といった影響パッケージ名が含まれていないかです。数分で終わる文字列検索で、影響の有無を切り分けられます。該当があれば、次の順で対応します。

  • 該当パッケージを npm uninstall で除去する
  • AWS・GitHub・npm・SSH など、その端末やCI環境が持つ全クレデンシャルを即座にローテーションする(preinstall フックが発火した時点で、どの認証情報が読み取られたかを個別に特定するのは現実的でないため、範囲を広く取る)
  • 加えて、侵害の影響範囲を絞り込みたい場合は、CI/CD のビルドログを遡り該当パッケージのインストールが走った時期を確認するのも有効です

恒久対策——npm ci --ignore-scripts をCI/CDの既定にする

今回のような攻撃が繰り返し発生する前提に立つなら、個別の対応だけでは追いつきません。GMO Flatt Security は、CI/CD で npm ci --ignore-scripts を標準化することを対応策として挙げています。--ignore-scripts を付けると、preinstall を含むライフサイクルフックの自動実行そのものを止められるため、「見えない実行スイッチ」を仕組みごと無効化できます。ネイティブモジュールのビルドなど正当な理由でインストール時スクリプトに依存するパッケージもあるため、導入時はビルドが壊れないかを一度確認したうえで、必要なパッケージだけ個別に許可する運用に倒すのが現実的です。加えて Aikido Security は、依存関係の手動・自動リスキャンと、継続的なサプライチェーン監視の導入検討を推奨しています。

まとめ

Shai-Hulud で見えたのは、攻撃者が悪意のあるパッケージを新規に公開したのではなく、正規のメンテナーのアカウント権限を奪って「本物のパッケージ」として配布した、という点です。パッケージ名や公開者を信頼するだけでは見抜けず、実行そのものを疑う仕組みが要ります。今すぐの確認は、自社が使っているロックファイル(package-lock.json・yarn.lock・pnpm-lock.yamlのいずれか)をひとつ検索するだけで始められ、恒久対策は CI/CD の設定行1行の変更から始められます。次に npm install を打つ前に、まず自社の lockfile を検索してみてください。


出典

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)

AI

AI導入やシステム開発の ご相談を承っています。

お気軽にお問い合わせください