概要

2026年8月4日、週間1億件を超えるダウンロード数を誇る人気npmパッケージ「keyv」をはじめとする一連のパッケージが、GitHubアカウント侵害を通じて汚染される大規模サプライチェーン攻撃が発生した。攻撃コードはpreinstallスクリプトとして仕込まれ、開発環境やCI環境でGitHub認証情報、npmレジストリアクセス権、クラウド認証情報、Vault・Kubernetes・データベースの認証材料などを窃取した。監視ツールによれば被害はSafeDepの検証で79パッケージ名・353バージョンに及び、Aikidoの報告ではさらに広く868パッケージ・1,381バージョンに達したとされる。攻撃は自動化されたワームとして機能し、2〜7分ごとに侵害した組織アカウントから次の組織へと移動し、約30分で横断的な公開バーストを完了させたと分析されている。

攻撃手法の技術的詳細

最初の悪意あるリリースであるkeyv@6.0.0は、インストール時に自動実行されるpreinstallスクリプトを通じて認証情報窃取バンドルを実行する設計だった。setup.mjsとMath_Symbol.jsという2つのファイルが仕込まれ、まずBunランタイムの有無を確認し、必要であればGitHubから1.3.13版のBunをダウンロードした上で、727,680バイトのコンパイル済みバンドルに制御を委譲する多段構成となっていた。攻撃者はGitHubアカウントの侵害によって取得した権限を悪用し、正規のGitHub Actionsリリースワークフローを通じてOIDC/SLSA証明付きの「正規リリース」として悪意あるパッケージを公開した。コミット自体もgithub-actions[bot]名義で検証済みバッジ付きだったが、専門家はこのバッジが署名パスの有効性を示すのみでソースコードの安全性までは保証しないと指摘している。同様にOIDC/SLSA証明もビルドプロセスの出所を特定できるに過ぎず、ソースの安全性を確立するものではないという限界が改めて浮き彫りになった。

IDE・エディタへの実行経路の仕込み

今回の攻撃で特に問題視されているのが、開発者のローカル環境で自動実行されるツール設定への侵入である。.claude/settings.jsonにはセッション開始時に自動実行されるSessionStartフックが仕込まれ、.vscode/setup.mjsを呼び出す構成になっていた。同様に.vscode/tasks.json内の「Environment Setup」タスクにはrunOn: folderOpenが設定され、フォルダを開いた際に.claude/setup.mjsを自動実行する仕掛けが組み込まれていた。ただしVS Codeは信頼されていないワークスペースでの自動タスク実行をブロックし、デフォルトでは実行前にユーザーへ確認プロンプトを表示するため、無条件で実行されるわけではない点は留意が必要である。とはいえ、開発ツールのワークスペース設定ファイルという開発者が見落としがちな場所に実行経路を仕込む手口は、今後同種の攻撃が広がる可能性を示唆している。

発見・対応状況とマルウェアファミリーとの関連

8月4日午後5時40分(IST)頃には、keyv@5.6.0やflat-cache@6.1.23、cache-manager@7.2.9など複数パッケージで、汚染前の以前のバージョンが「latest」タグに復元される対応が取られた。その後の続報では、keyvおよびCacheableの毒物化リリースは非公開化されたものの、それ以外のほぼすべての被害パッケージでは「latest」タグが依然として悪意あるバージョンを指したままであると報告されている。セキュリティ企業Aikidoはこの攻撃を既知のマルウェアファミリー「Shai-Hulud」に位置づけており、セキュリティ企業Semgrepは同一のClaude Code・VS Codeフック、setup.mjsというファイル名、Bun 1.3.13のダウンロード手口が、2026年4月に発生したPyPIのlightning(pytorch-lightning)パッケージ侵害でも確認されていたと報告している。報道時点では、メンテナー・npm・GitHubいずれからも公式声明は出されていない。

推奨される対策と今後の見通し

専門家はlockfileと実際に解決されたバージョンをパッケージ名単位で正確に照合すること、不要なインストールスクリプトを無効化すること、そして影響を受けたバージョンを実行した環境はすでに侵害されたものとして扱うことを推奨している。npm 12ではデフォルトで未承認のライフサイクルスクリプトがブロックされるようになっているが、旧バージョンのクライアントやライフサイクルスクリプトの実行を許可する設定を残した環境は依然として脆弱なままだ。正規のCI/CD証明やコミット署名だけでは供給元の安全性を保証できないことが改めて示された今回の事例は、開発ツールの自動実行設定を含めた多層的なサプライチェーン防御の必要性を浮き彫りにしている。