npmサプライチェーンワームの全容｜Claude CodeとVS Codeが狙われた手口と今日やるべき3つのこと【2026年8月】

結論: 2026年8月4日、月間1.27億ダウンロードを誇るnpmパッケージ「keyv」のメンテナーアカウントが侵害され、認証情報を窃取する自己増殖型ワームが444パッケージ・2,234バージョンに拡散しました。このワームはClaude Codeのセッション開始フックとVS Codeの自動タスクに悪意あるコードを仕込む経路を持ち、開発者のGitHubトークン・AWSキー・npmトークンなどを窃取します。特筆すべきは、盗んだトークンをローテーション（失効）すると攻撃者のコードが発火する「dead-man's switch」が仕込まれている点で、標準的なインシデント対応手順が裏目に出る構造になっています。

この記事の要点:

• keyvファミリーのnpmパッケージが侵害され、12組織・444パッケージに自己増殖するワームが拡散。影響パッケージの月間ダウンロード合計は20億超（SafeDep 2026年8月4日確認）
• ワームはClaude Codeの.claude/settings.jsonとVS Codeの.vscode/tasks.jsonにフックを設置し、リポジトリをクローンした開発者にも感染経路を作った（The Hacker News 2026年8月報道）
• 盗んだトークンの失効を検知して攻撃コードを発火させる「dead-man's switch」があるため、ウォッチャーの除去→トークンローテーションの順序が必須（SafeDep 2026年8月4日報告）

対象読者: npmを日常的に使っている開発者、Claude CodeやVS Codeで開発しているエンジニア、SES現場でAIコーディングツールの利用ルール策定に関わる方

読了後にできること: 自分の環境が影響を受けているかを確認し、安全な順序でトークンをローテーションする手順がわかります。また、今後のサプライチェーン攻撃に対して「来歴署名だけでは防げない」という前提で防御を設計する判断軸が持てます

keyvパッケージが侵害された——何が起きたのか

2026年8月4日、セキュリティ企業SafeDepがnpmレジストリ上で異常な公開パターンを検出しました。keyv（キーバリューストレージライブラリ、月間1.27億ダウンロード）のメンテナーが管理する複数のパッケージに、見慣れないファイルが追加されていたのです。

keyvの影響範囲が大きいのは、このメンテナーが同時にcacheable（月間2,900万DL）、flat-cache（月間5.65億DL）、file-entry-cache（月間5.57億DL）なども管理していたためです。1つのアカウントの侵害が、複数の広く使われるパッケージを一度に汚染する結果になりました。

僕自身、Claude Codeを全社導入してAI秘書「FRIDAY」を毎日動かしている立場なので、「.claude/settings.jsonにフックを仕込む」という攻撃経路を見たとき、他人事ではありませんでした。この記事では、何が起きたかを時系列で整理し、Claude Code・VS Codeユーザーが今日確認すべきことまで踏み込みます。

時系列で整理する——34分で12組織に拡散

SafeDepが公開した技術タイムラインによると、攻撃は以下の流れで進行しました（SafeDep 2026年8月4日公開）。

| 時刻（UTC） | できごと | |---|---| | 09:02:37 | 悪意あるリリースコミット（署名なし） | | 09:04:30 | IDE（Claude Code・VS Code）フックのコミット。GitHub Actions botとして署名偽装 | | 09:23:50 | テストファイルの痕跡を削除するクリーンアップコミット | | 09:35:00 | 最初の汚染バージョンがnpmに公開 | | 10:12〜10:46 | 34分間で8組織のパッケージに連鎖感染 | | 13:18:05 | 最後の組織（Umacloud）に到達。全12組織の汚染完了 |

注目すべきは、最初のコミットから最初のnpm公開までわずか33分、そこから12組織への拡散完了まで約3時間43分という速度です。ワームは盗んだnpmトークンを使って自動的に再パッケージ・再公開を行う機構を内蔵しており、1パッケージあたり約1秒のペースで汚染を広げました。

SafeDepの最終集計では、444パッケージ・2,234バージョンが汚染されたと報告されています（SafeDep 2026年8月4日）。別の分析を行ったSocket社は868パッケージ・1,381バージョン、Aikido社はさらに異なる数値を報告しており、計測手法の違いで数字にばらつきがあります。いずれにしても、影響を受けたパッケージの月間ダウンロード合計は20億を超える規模です。

ワームの仕組み——「npm install」で何が起きるか

攻撃の仕組みを段階的に説明します。

Stage 1: preinstallフックの注入

汚染された各パッケージのpackage.jsonに、以下の1行が追加されました。

"preinstall": "node setup.mjs"

npm installを実行すると、ユーザーのコードよりも先にsetup.mjsが自動実行されます。これはnpmの正規の仕組み（ライフサイクルスクリプト）を悪用したもので、特別な権限は必要ありません。

Stage 2: Bunランタイムのダウンロード

setup.mjsはまずBunランタイム（v1.3.13）がインストールされているか確認し、なければ公式のGitHub Releasesからダウンロードします。攻撃者独自のサーバーではなく正規のインフラを使うため、URLベースのブロックリストでは検出できません。

Stage 3: 暗号化された窃取ペイロードの実行

ダウンロードしたBunで727KBのバンドルファイルを実行します。このバンドルにはbasE91エンコーディングとAES-256-GCM暗号化で保護された10個のペイロードが含まれており、以下の認証情報を窃取します（SafeDep 2026年8月4日報告）。

| 窃取対象 | 検出パターン | |---|---| | GitHubトークン | ghp_、ghs_プレフィックス | | npmレジストリトークン | .npmrcファイル | | AWS認証キー | AKIAプレフィックス | | GCPサービスアカウント | JSON鍵ファイル | | Azure認証情報 | 環境変数・設定ファイル | | Stripeキー | API鍵 | | Vaultトークン | Vault設定 | | Kubernetesサービスアカウント | kubeconfig | | データベースURL | インライン認証情報つきURL | | 秘密鍵 | SSH・PGPなどの鍵ファイル |

さらに、GitHub Actions実行環境ではランナーメモリ内のマスクされたシークレットや/actions/secrets APIエンドポイントからも情報を取得しようとします。

Stage 4: 自己増殖

ワームの最大の特徴は、盗んだnpmトークンを使って新たなパッケージを汚染・再公開する自己増殖機構を内蔵している点です。バンドル内にはnpm公開機構に加え、OIDCトークン交換・Fulcio・Rekorクライアントまで含まれており、正規のSLSA署名付きで再公開できます。

Claude CodeとVS Codeが狙われた——IDEフックという攻撃経路

今回の攻撃で特に注目すべきは、npmの依存関係だけでなく、リポジトリをクローンした開発者にも感染経路を作った点です。

keyvリポジトリのメインブランチに、以下のファイルが追加されました（The Hacker News 2026年8月報道）。

Claude Codeへのフック

.claude/settings.jsonにSessionStartフックが設定され、セッション開始時に.vscode/setup.mjsを実行するよう仕組まれていました。

VS Codeへのフック

.vscode/tasks.jsonにrunOn: folderOpen（フォルダを開いた時に自動実行）のタスクが設定され、.claude/setup.mjsを実行するよう仕組まれていました。

実際の危険度はどの程度か

ここで重要な補足があります。VS Codeは信頼されていないワークスペースでは自動タスクの実行前にユーザーに確認を求めます（The Hacker News 2026年8月報道）。Claude Codeも同様に、未知のフックについてはプロンプトを出す設計です。つまり、デフォルト設定であれば無条件に実行されるわけではありません。

ただし、以下のケースでは危険度が上がります。

• 過去にそのリポジトリを信頼済みとしてマークしている場合
• 自動タスク実行を許可する設定にしている場合
• .claude/や.vscode/ディレクトリの変更を確認せずにpullした場合

フックファイルは汚染されたnpmパッケージのバンドル内にも含まれており、npm install経由でも.claude/や.vscode/にファイルが生成される可能性があります。

dead-man's switch——トークンをローテーションすると発火する罠

今回の攻撃で最も厄介な仕組みが、**dead-man's switch（デッドマンスイッチ）**です。

通常、認証情報の漏洩が判明したときの最初の対応は「すぐにトークンをローテーション（失効・再発行）する」ことです。しかし、このワームはその標準対応を逆手に取る設計になっています（SafeDep 2026年8月4日報告）。

仕組みはこうです。

1. ワームは盗んだGitHubトークンを使って、60秒ごとにGitHub APIにポーリングするウォッチャープロセスを常駐させる
2. APIが40x（認証エラー）を返した場合＝トークンが失効した場合、攻撃者が指定した**eval()ハンドラが発火**する
3. このハンドラは任意のコードを実行できる権限を持つ

つまり、「トークンを急いでローテーションする」という正しいはずの対応が、追加の攻撃コードを起動するトリガーになるのです。

ウォッチャーは以下の場所に常駐します。

| OS | 常駐方法 | パス | |---|---|---| | macOS | LaunchAgent | com.user.gh-token-monitor | | Linux | systemd ユーザーサービス | 24時間TTL |

関連ファイルの所在:

• ~/.config/gh-token-monitor/token
• ~/.config/gh-token-monitor/handler
• ~/.config/gh-token-monitor/started_at
• ~/.local/bin/gh-token-monitor.sh

したがって、正しい対応順序は「まずウォッチャーを見つけて除去する → その後でトークンをローテーションする」です。

来歴署名（SLSA/OIDC）を突破した——「署名済み＝安全」ではない

今回の攻撃で業界に衝撃を与えたもう一つの事実があります。汚染されたパッケージは正規のOpenID Connect（OIDC）およびSupply-chain Levels for Software Artifacts（SLSA）来歴署名を持っていました（SafeDep 2026年8月4日報告）。

なぜそうなったかというと、攻撃者は正規のGitHub Actionsワークフローを通じてパッケージを公開したためです。CIパイプライン自体は正常に動作し、署名プロセスも正しく完了しました。しかし、パイプラインに投入されたソースコード自体が汚染されていたのです。

SafeDepはこれを「来歴はソースが安全であることを証明しない。パイプラインが正常に動作したことだけを証明する」と指摘しています。

npm公式が推進してきた「来歴署名をチェックすればサプライチェーン攻撃を防げる」という前提は、この攻撃によって構造的に破られました。

窃取データの流出先——GitHubインフラ上のdead-drop

攻撃者はC2（コマンド＆コントロール）サーバーを自前で用意していません。窃取したデータはAES-256-GCMで暗号化し、その鍵をRSA-4096でラッピングしたうえで、GitHubリポジトリをdead-drop（受け渡し場所）として利用しています（SafeDep 2026年8月4日報告）。

8月4日だけで、「Shai-Hulud: Here We Go Again」という説明文を持つリポジトリが546個出現しました。「Shai-Hulud」は2026年5月11日のTanStackパッケージ侵害でも使われたマーカーで、同一キャンペーンとの関連が指摘されています。

すべてのトラフィックがGitHub所有のインフラを経由するため、IPアドレスやドメインのレピュテーションに基づく防御は機能しません。

どこまで確認されているか——検証状況

確認済みの事実

• 汚染の事実と規模は複数の独立したセキュリティ企業（SafeDep、Socket、Aikido）がそれぞれ独自に分析・確認しています。パッケージの汚染バージョンはnpmレジストリ上で実測可能です
• Claude Code・VS Codeフックの存在は、keyvリポジトリのメインブランチ上で直接確認されています（8月4日17:40 IST時点で.claude/ディレクトリが残存）
• dead-man's switchの存在はSafeDepが逆コンパイルしたペイロードから確認しています

注意すべき点

• 各社の報告する影響パッケージ数・バージョン数に差異があります（SafeDep: 444パッケージ/2,234バージョン、Socket: 868/1,381）。スキャン範囲と計測手法の違いによるもので、どの数字が「正しい」かは断定できません
• dead-man's switchのeval()ハンドラの実行内容は現時点で完全には解明されていません（暗号化されているため）。SafeDepは「任意のコードを実行できる権限を持つ」と報告していますが、具体的にどのようなコードが実行されるかは未検証です
• メンテナーアカウントの侵害経路（フィッシング・トークン窃取・別の侵害の連鎖等）は各報告とも特定に至っていません

楽観論と慎重論——受け止め方

楽観的な見方

• npmエコシステム側の対応は速く、影響を受けたパッケージの多くは数時間以内に以前の安全なバージョンに巻き戻されています
• VS CodeやClaude Codeのデフォルト設定では、未信頼ワークスペースでの自動タスク実行にはユーザー確認が入るため、IDEフック経由の感染は限定的と考えられます
• SafeDepが詳細な技術タイムラインを公開したことで、影響の有無を自分で確認できる状態になっています

慎重な見方

• keyvはWebフレームワークやCLIツールの深い依存関係に入り込んでいるため、直接インストールしていなくても間接的に影響を受けている可能性があります。自分のlockfileを確認しない限り安全とは言えません
• 来歴署名を突破したことで、「署名を確認すれば安全」というサプライチェーン防御の基本的な前提が崩れています。代替の防御策はまだ確立されていません
• dead-man's switchの存在は、インシデント対応の手順そのものを見直す必要性を示唆しています。「まずトークンをローテーション」という業界の常識が、この種の攻撃に対しては有害になり得ます
• 「Shai-Hulud」マーカーがTanStack侵害（2026年5月）と共通していることは、このキャンペーンが一回限りではなく継続的に進化していることを示しています

デュスクとしての見立て

今回の攻撃は「npmのセキュリティが甘い」という話ではなく、ソフトウェアサプライチェーン全体の信頼モデルが追いついていないことを示しています。来歴署名は「正規のパイプラインを通った」ことを証明しますが、「ソースが安全である」ことは証明しません。この構造的なギャップは、npm固有ではなくpypi・Cargoなど他のパッケージレジストリにも共通する問題です。SES現場でクライアント環境に依存関係を持ち込むエンジニアにとって、「自分がインストールしたものが何か」を説明できる準備は、もはや選択ではなく必須になっています。

エンジニア・SES現場への示唆

ここからが本題です。

Claude Code・VS Codeユーザーへの直接的な影響

SES現場でClaude CodeやVS Codeを使っている場合、2つの経路で影響を受ける可能性があります。

経路1: npm install経由。影響のあるパッケージを直接的または間接的にインストールした場合、preinstallスクリプトが実行され、認証情報が窃取された可能性があります。

経路2: リポジトリクローン経由。keyvやcacheableなどのリポジトリをクローンし、Claude CodeやVS Codeで開いた場合、フックファイルが存在します。VS Codeのデフォルト設定では確認プロンプトが出ますが、信頼済みワークスペースとしてマークしていた場合は自動実行された可能性があります。

CIパイプラインのリスク

GitHub Actionsでnpm installを実行しているCIパイプラインは、ランナーの実行環境に保存されたシークレットが窃取された可能性があります。特に、環境変数として渡しているAWSキーやデータベース接続情報に注意が必要です。

常駐先環境での対応

SESエンジニアが常駐先の環境で開発している場合、影響の有無を常駐先のセキュリティチームに報告する必要があります。特に、以下の点を伝えるべきです。

• 影響時間帯（8月4日 09:35〜13:18 UTC）にnpm installを実行した可能性があるか
• lockfileにkeyv・cacheable・flat-cacheなどの影響パッケージが含まれているか
• dead-man's switchの除去が完了するまでトークンのローテーションを保留すべきであること

今すぐ確認・検討すべきこと

• 今日確認すること: 自分のプロジェクトのpackage-lock.json（またはyarn.lock・pnpm-lock.yaml）をSafeDepが公開している影響パッケージリストと突き合わせる。ローカル環境に~/.config/gh-token-monitor/ディレクトリや、.claude/settings.json・.vscode/tasks.jsonに見覚えのないフック設定がないか確認する
• 今週中にやること: dead-man's switchのウォッチャープロセス（macOS: com.user.gh-token-monitor LaunchAgent、Linux: systemdユーザーサービス）を検索・除去したうえで、影響時間帯に使用していたnpmトークン・GitHubトークン・AWSキーをローテーションする。CIパイプラインのGitHub Actions secretsも棚卸しする
• 今月中に検討すること: CIパイプラインでnpm config set ignore-scripts trueを設定し、preinstallスクリプトの自動実行を無効化する。来歴署名だけに頼らない依存関係の検証プロセス（lockfileの定期監査・依存関係の変更レビュー）をチームの運用に組み込む

よくある質問

Q1: keyvを直接使っていなければ安全ですか？ 直接依存していなくても、keyvやflat-cacheは多くのパッケージの間接的な依存関係として含まれています。npm ls keyvやnpm ls flat-cacheを実行して間接依存を確認してください。ただし、lockfileが8月4日09:35 UTC以前に固定されていれば、汚染バージョンはインストールされていません。

Q2: Claude Codeのフックは自動で実行されますか？ Claude Codeは未知のフック設定に対してユーザーに確認を求める設計です。ただし、過去にそのリポジトリのフックを許可していた場合や、すべてのフックを自動許可する設定にしている場合は注意が必要です。.claude/settings.jsonを確認し、身に覚えのないSessionStartフックがあれば削除してください。

Q3: なぜトークンのローテーションを急いではいけないのですか？ ワームが常駐させたウォッチャープロセスが、トークンの失効（ローテーション）を検知して攻撃コードを発火させる仕組みになっているためです。先にウォッチャー（~/.config/gh-token-monitor/および関連するLaunchAgent/systemdサービス）を除去してからローテーションしてください。

Q4: 来歴署名（SLSA）をチェックしていても防げなかったのですか？ 防げませんでした。攻撃者は正規のGitHub Actionsワークフローを通じてパッケージを公開したため、来歴署名は正しく付与されました。来歴署名は「このパッケージは正規のCIパイプラインで作られた」ことを証明しますが、「ソースコードが安全である」ことは証明しません。

Q5: 前回のTanStack侵害（2026年5月）と同じ攻撃者ですか？ SafeDepは、GitHubのdead-dropリポジトリに「Shai-Hulud: Here We Go Again」という同一のマーカーが使われていること、およびペイロードの構造に共通点があることを報告しています。同一の攻撃者またはキャンペーンである可能性が高いとされていますが、確定はしていません。

まとめ

keyvファミリーのnpmサプライチェーン攻撃は、認証情報の窃取だけでなく、Claude CodeやVS Codeのフックを悪用した感染経路の確立、来歴署名の構造的な突破、そしてインシデント対応そのものを逆手に取るdead-man's switchという、複数の新しい手法を組み合わせた攻撃でした。

確定しているのは、8月4日に12組織のnpmパッケージが汚染され、複数のセキュリティ企業が独立に検証・確認したという事実です。Claude Code・VS Codeのフック経由の感染については、デフォルト設定ではユーザー確認が入るため無条件に実行されるわけではありませんが、信頼済みワークスペースでは危険度が上がります。

「Shai-Hulud」キャンペーンがTanStack侵害から3か月足らずで再び動いたことを考えると、この種の攻撃は今後も続くと見るべきです。「自分のlockfileを確認する」「preinstallスクリプトを無効化する」「来歴署名だけに頼らない」——地味ですが、これらの対策がサプライチェーン攻撃に対する現時点で最も確実な防御線です。

参考・出典

• npm Worm Poisons keyv, cacheable and 400+ Other Packages Across Twelve Organisations（https://safedep.io/keyv-npm-supply-chain-compromise/） — SafeDep（参照日: 2026-08-06）。技術タイムライン・ペイロード解析・影響パッケージリスト・remediation手順の一次情報【一次】
• Keyv-Linked npm Worm Poisons Hundreds of Packages, Plants Claude Code and VS Code Hooks（https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html） — The Hacker News（参照日: 2026-08-06）。Claude Code/VS Codeフックの技術詳細・dead-man's switchの分析
• Keyv and friends compromised in npm supply chain attack（https://www.aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack） — Aikido（参照日: 2026-08-06）。初期検出・影響パッケージの独自集計
• The keyv and cacheable npm Supply Chain Attack: Inside the Mini Shai-Hulud Campaign（https://www.chainguard.dev/unchained/the-keyv-and-cacheable-npm-supply-chain-attack-inside-the-mini-shai-hulud-campaign） — Chainguard（参照日: 2026-08-06）。Shai-Huludキャンペーンの分析・SLSA来歴署名突破の考察
• keyv and cacheable npm Package Hijacked in Supply Chain Attack（https://www.wiz.io/blog/keyv-and-cacheable-npm-supply-chain-attack） — Wiz（参照日: 2026-08-06）。クラウドセキュリティ観点からの影響分析
• Keyv npm Supply Chain Attack: Cacheable Compromise and CI/CD Credential Theft（https://www.penligent.ai/hackinglabs/keyv/） — Penligent（参照日: 2026-08-06）。CI/CDパイプラインへの影響分析