ChainDrop: keyv含む400超のnpmパッケージが自己増殖ワームで侵害 — Claude Code/VS Codeにも永続化

この記事は約17分で読めます。

Microsoft Threat Intelligenceは2026年8月4日、400件を超えるnpmパッケージへ急速に拡大した大規模サプライチェーン攻撃「ChainDrop」を公表しました。悪意あるパッケージには、認証情報を窃取しながら別のnpmパッケージへ自己増殖するMini Shai-Hulud系のワームが組み込まれていました。

セキュリティ企業StepSecurityは、同日18時10分(UTC)時点で444パッケージ、2,212バージョンが汚染されたと集計しています。攻撃は4時間未満で複数の無関係な発行者へ波及し、広く利用されるkeyv、flat-cache、file-entry-cache、cache-managerなども影響を受けました。ただし、調査とnpm側の削除対応は進行中であり、件数や対象バージョンは今後更新される可能性があります。

ChainDropは、開発端末や継続的インテグレーション・継続的デリバリー(CI/CD)環境から、npm、GitHub、クラウド、Kubernetes、HashiCorp Vaultなどの認証情報を収集します。取得したnpm公開権限を使って、被害者が管理する別のパッケージへ自身を埋め込み、パッチバージョンを上げて再公開することが特徴です。

今回の攻撃では、一部の悪意あるパッケージが正規のGitHub ActionsとOpenID Connect(OIDC)による信頼された公開経路を通じて配布され、ソフトウェア成果物のサプライチェーンレベル(Supply-chain Levels for Software Artifacts、SLSA)に基づく正当な来歴証明も付与されていました。来歴証明が有効であることだけでは、公開処理を開始した人物やコミットが正当であることまで保証できないという、ソフトウェアサプライチェーン防御上の重要な課題も示されています。

ChainDropの概要

項目 内容
攻撃名 ChainDrop
攻撃種別 自己増殖型npmサプライチェーン攻撃
確認日 2026年8月4日
Microsoftの影響集計 400件を超えるnpmパッケージ
StepSecurityの時点集計 2026年8月4日18時10分(UTC)時点で444パッケージ、2,212バージョン
初期の主要パッケージ keyv、flat-cache、file-entry-cache、cacheable-request、cache-managerなど
実行経路 npmのpreinstallライフサイクル処理からsetup.mjsを実行
第2段階 正規のBunランタイムを利用して難読化されたJavaScriptを実行
主な標的 開発者端末、CI/CDランナー、GitHub Actions
窃取対象 npm・GitHubトークン、クラウド認証情報、SSH鍵、環境変数、ワークフローシークレット、Kubernetes・Vaultの秘密情報
自己増殖 取得したnpm公開権限で別パッケージを改変し、パッチバージョンを増やして再公開
追加の永続化 Claude CodeやVisual Studio Codeの設定ファイルをリポジトリへ追加
外部通信先の解決 Ethereumコントラクトと署名済みGitHubコミットから現在の送信先を取得
主な外部通信先 npm-cache[.]com、pypi-get[.]com、js-mirror[.]com
推奨対応 対象バージョン確認、端末・CI/CDの隔離、キャッシュ削除、認証情報の無効化・再発行、信頼できる状態からの再構築

444パッケージ・2,212バージョンへ4時間未満で拡大

StepSecurityは、8月4日9時40分から13時20分(UTC)の間に、悪意あるnpmパッケージが急増したことを観測しました。同社の18時10分時点の集計では、444パッケージと2,212件の悪意あるバージョンが確認されています。

一方、Aikidoは同日13時37分(中央ヨーロッパ夏時間)時点で434パッケージ、1,381バージョンと集計しています。各社で確認時刻、重複除外、過去バージョンの扱いが異なるため、件数は単純比較できません。本記事では、Microsoft公式の「400件超」を全体表現として使用し、StepSecurityとAikidoの数字は時点集計として区別します。

この集計は、次の2層に分けられています。

  • 第1層:完全なワーム本体を含む11件のパッケージ
  • 第2層:窃取された認証情報を使ってワーム自身が再公開した433件のパッケージ、2,201バージョン

第1層として確認されたパッケージと悪意あるバージョンは次のとおりです。

パッケージ 悪意あるバージョン
keyv 6.0.0
flat-cache 6.1.24
file-entry-cache 11.1.6
cacheable-request 13.0.20
@cacheable/utils 2.5.1
cacheable 2.5.1
@cacheable/memory 2.2.1
cache-manager 7.2.10
@cacheable/node-cache 3.1.2
ecto 5.0.1
@cacheable/net 2.1.1

ただし、この11件だけを確認すればよいわけではありません。ワームは別の発行者が管理するパッケージへ再公開を繰り返し、同じパッケージの過去バージョンを含む多数のバージョンへペイロードを追加しました。調査時点の完全な対象一覧はStepSecurityの脅威情報で更新されているため、ロックファイルや成果物を確認する際は最新の一覧を使用する必要があります。

攻撃はどのように始まったのか

Microsoftは、初期侵害について、メンテナーの認証情報が窃取された可能性を示しています。StepSecurityの分析では、最初の攻撃はJared Wray氏が所有していたkeyv、cacheable、ectoの3つのGitHubリポジトリから始まったとされています。

StepSecurityによると、第1波の悪意あるパッケージは、長期間有効なnpmトークンを使って直接公開されたものではありません。攻撃者はメンテナーのGitHubアカウントまたはセッションを侵害し、悪意あるコミットとリリースを正規リポジトリへ追加した上で、各プロジェクトが使用するGitHub Actionsの公開処理を実行しました。

その結果、keyv@6.0.0などには、正規のGitHub Actions OIDCによるnpmの信頼された公開と、有効なSLSA来歴証明が付与されました。自動化された検査から見ると、「正規リポジトリの正規ワークフローから公開されたパッケージ」に見える状態です。

有効なSLSA来歴証明でも防げなかった理由

SLSA来歴証明は、どのソース、コミット、ワークフローから成果物が作られたかを確認するための重要な仕組みです。しかし、証明対象となるソースコードやリリース操作そのものが攻撃者によって改変されていた場合、来歴証明は攻撃者のコミットを正確に記録します。

つまり、今回の証明が偽造されていたわけではありません。証明は正しく、悪意あるコミットから正規ワークフローを通じてパッケージが作成されたことを示していました。

StepSecurityはこの点について、来歴証明は「どのコミットがビルドされたか」を証明できても、「そのコミットが正当に承認されたか」までは証明できないと説明しています。

そのため、公開物に有効なSLSA証明があることだけを安全性の条件にするのではなく、次の確認も必要です。

  • コミットの正当性:署名、レビュー、作成者、変更内容が通常の開発手順と一致するか
  • リリースの正当性:対応するIssue、Pull Request、タグ、リリースノートが存在するか
  • 権限の異常:メンテナーアカウント、GitHub App、OIDC公開設定に不審な変更がないか
  • 公開の異常:短時間に多数のパッチバージョンが公開されていないか
  • 新規ライフサイクル処理:preinstall、install、postinstallが突然追加されていないか

preinstallからBunを起動して第2段階を実行

汚染されたパッケージには、npmのインストール前処理であるpreinstallからsetup.mjsを起動する設定が追加されていました。npmはパッケージのインストールが完了する前にpreinstallを実行するため、アプリケーションのテストや一般的なビルド後検査より先にペイロードが動作する可能性があります。

setup.mjsは、端末にBunが存在するか確認します。存在しない場合は、Bunの公式GitHubリリースからOSとCPUに合う正規のランタイムを取得し、パッケージ内のMath_Symbol.jsまたはmath_init.jsを実行します。

ここで悪用されているのはBunの脆弱性ではありません。攻撃者は正規のJavaScriptランタイムを実行基盤として利用し、Node.jsだけを監視する検知を回避しやすくしています。Linux、macOS、Windowsに対応するため、開発端末だけでなく、各OSのビルドランナーも影響を受けます。

Ethereumを使って送信先を切り替えるEtherHiding

ChainDropは、Ethereumブロックチェーン上のコントラクトから、窃取情報の送信先となるドメインを取得します。このようにブロックチェーンを外部通信先の解決へ利用する手法は、EtherHidingと呼ばれます。

Microsoftの分析では、コントラクトは調査時点でnpm-cache[.]comを返し、過去にはpypi-get[.]comとjs-mirror[.]comも候補として使われていました。送信先は署名済みGitHubコミットから取得する予備経路も備えています。

窃取情報自体は、HTTPSエンドポイントまたは攻撃者が作成したGitHubリポジトリへ送られます。固定ドメインの遮断だけでは不十分なため、コントラクト照会やGitHub上の異常なリポジトリ作成も確認してください。

開発端末とCI/CDで動作を切り替える

Microsoftの分析によると、ワームは自身が開発者端末とCI/CD環境のどちらで動作しているかを判定します。

  • 開発端末:インストール処理の終了後も動作を続けられるよう、バックグラウンドプロセスとして起動
  • CI/CD環境:実行中のジョブへ残り、ワークフローシークレット、ランナーの認証情報、OIDC公開権限へアクセス

収集対象は、単に設定ファイル内の文字列を探すだけではありません。取得した認証情報を使って各サービスのAPIへ接続し、トークンの有効性や権限を確認した上で、アクセス可能な追加情報を列挙します。

  • npm:公開可能なパッケージと発行権限
  • GitHub:書き込み可能なリポジトリ、トークンの権限、GitHub Actionsのシークレット
  • AWS:認証情報、パラメータ、アクセス可能なクラウド資源
  • Kubernetes:設定ファイル、クラスター認証情報
  • HashiCorp Vault:アクセス可能な秘密情報
  • 端末:環境変数、シェル履歴、SSH鍵、クラウドCLI設定

取得したnpm権限で別パッケージへ自己増殖

ChainDropの最も大きな特徴は、窃取したnpm公開権限を使って次の被害を自動生成することです。

ワームは、侵害した利用者が公開できるパッケージを列挙し、それぞれの最新の圧縮アーカイブ(tarball)を取得します。その中へ自身のペイロードとローダーを追加し、preinstall処理を設定した上で、パッチバージョンを増加させてnpmへ再公開します。

Claude CodeとVisual Studio Codeの設定へ永続化

Microsoftは、ワームが盗んだGitHub認証情報を使い、リポジトリ内のClaude CodeとVisual Studio Codeの設定パスへファイルを追加する機能を確認しています。

  • .claude/settings.json
  • .claude/setup.mjs
  • .vscode/tasks.json
  • .vscode/setup.mjs

これらの設定によって、元のnpmインストールが終了した後でも、開発者が対象リポジトリを開いたり、AIコーディングツールを起動したりした際にペイロードが再実行される可能性があります。

トークン無効化で作動する自己消去機能

Socketは、macOSとLinuxで動作するホスト側の監視機能も確認しています。ワームは盗んだGitHubトークンの有効性を60秒ごとに確認し、トークンが無効化されてHTTP 4xxが返ると、外部から設定された処理を実行した後、自身の状態を削除して終了します。24時間経過後にも自動的に消去されます。

主な痕跡は、~/.local/bin/gh-token-monitor.sh、~/.config/gh-token-monitor/、macOSのcom.user.gh-token-monitor、Linuxのgh-token-monitor.serviceです。Microsoftも、GitHubトークンを監視し、失効時に破壊的な処理を実行できるコンポーネントを確認しています。

影響端末では、トークンを失効させる前に端末を隔離し、証拠と監視サービスの処理内容を確認してください。自己消去後も侵害が解消したとは限りません。

ロックファイルがあっても防げないケース

package-lock.json、yarn.lock、pnpm-lock.yamlをリポジトリへ保存し、依存バージョンを固定することは重要な対策です。しかし、StepSecurityが確認したBackstageのCI実行例では、コミット済みのロックファイルが変更されていないにもかかわらず、ChainDropのペイロードが実行されました。

該当するテストは、新しいアプリケーションを生成し、その場で最新の依存関係を取得する処理を行っていました。この処理は既存リポジトリのロックファイルの外側で実行されるため、レジストリ上の最新バージョンが直接解決されます。

テンプレート検証、スキャフォールディングテスト、サンプルアプリ作成、クイックスタート検証など、毎回新しいプロジェクトを作るCI処理では同様のリスクがあります。依存関係の固定に加え、新しい公開バージョンをすぐには採用しないクールダウン期間や、インストールスクリプトの許可制が必要です。

影響を受けた可能性がある環境

次の条件に該当する場合は、開発端末またはCI/CDランナーが侵害された可能性を前提に調査してください。

  • 対象バージョンの導入:直接依存または推移的依存として、悪意あるバージョンをインストールした
  • ライフサイクル処理が有効:preinstallなどのインストールスクリプトを許可した状態だった
  • 最新依存の動的取得:CIやテストがロックファイルを使わず、最新バージョンを取得した
  • 共有キャッシュ:npm、yarn、アーティファクト管理基盤へ汚染tarballが保存された
  • 共有ランナー:複数プロジェクトが同じCI/CDランナーやベースイメージを使用した
  • 権限のある認証情報:実行環境にnpm公開トークン、GitHubトークン、クラウド認証情報が存在した

侵害調査で確認すべき項目

確認対象 主な確認内容
依存関係 ロックファイル、ソフトウェア部品表(SBOM)、ビルドログ、成果物に悪意あるname@versionが含まれていないか
npm・yarnキャッシュ 削除済みの悪意あるtarballや展開済みファイルが残っていないか
端末・ランナー setup.mjs、Math_Symbol.js、Math_init.js、math_*.js、想定外のBunプロセス
自己消去機能 gh-token-monitor.sh、gh-token-monitorディレクトリ、LaunchAgent、systemdユーザーサービス
ブロックチェーン照会 Ethereumコントラクト0xE1f2395ee43e45A1556EC6438a88c31B83493103へのアクセス
リポジトリ .claude、.vscode、GitHub Actionsワークフロー、見覚えのないコミットやブランチ
npm 未承認のパッチバージョン、公開履歴、トークン、メンテナー権限
GitHub 不審なトークン利用、リリース、タグ、GitHub App、OIDC公開設定
クラウド・秘密管理 AWS、Kubernetes、Vaultなどへの異常な列挙やシークレット参照
ネットワーク npm-cache[.]com、pypi-get[.]com、js-mirror[.]comへの通信
成果物 影響期間中に作成されたコンテナ、パッケージ、配布ファイルの完全性

ハッシュやドメインが見つからないことだけで、安全とは判断できません。攻撃者は難読化やファイル名、通信先を変更できるため、通常と異なる公開、認証、プロセス、ネットワーク通信を時系列で確認する必要があります。

実務上の推奨対応

対象バージョンを導入した可能性がある組織は、次の順序で対応してください。

  • 最新一覧の取得:MicrosoftとStepSecurityが更新する対象パッケージ・バージョン一覧を取得する
  • 利用状況の特定:ロックファイル、ソフトウェア部品表(SBOM)、CIログ、キャッシュ、成果物から直接・推移的依存を検索する
  • 対象環境の隔離:対象バージョンを実行した開発端末とCI/CDランナーをネットワークから隔離する
  • 証拠保全:認証情報を無効化する前に、パッケージ、npm・CIログ、GitHub監査ログ、ランナーイメージを保全する
  • 永続化の確認:リポジトリのClaude Code、Visual Studio Code、GitHub Actions設定と端末上の不審ファイルを確認する
  • 自己消去機能の除去:macOSとLinuxでは、GitHubトークン監視サービスと関連ファイルを取り除いてからトークンを無効化する
  • キャッシュの削除:npm・yarnキャッシュ、社内レジストリ、アーティファクト保存先から汚染物を除去する
  • 認証情報の無効化:影響環境から到達できたnpm、GitHub、クラウド、SSH、Kubernetes、Vaultの認証情報を無効化する
  • クリーン環境で再発行:侵害の影響を受けていない端末から、新しいトークンと秘密情報を発行する
  • 端末とランナーの再構築:既知の正常なイメージから開発端末、CI/CDランナー、共有ベースイメージを再構築する
  • 成果物の再生成:影響期間中に作成したコンテナや配布物を破棄し、正常な依存関係から再ビルドする
  • 公開経路の監査:GitHub Actions OIDC、リリース承認、保護環境、メンテナー権限を見直す

認証情報の変更は、侵害された可能性がある端末から行わないでください。また、リポジトリや端末へ追加された永続化設定を残したまま新しい認証情報を投入すると、再び窃取される可能性があります。

今後のnpmサプライチェーン対策

Microsoftは、npm CLI v12への更新と、新しいパッケージバージョンを公開直後には導入しないmin-release-age機能の使用を推奨しています。

npm v12では、依存パッケージのpreinstall、install、postinstallなどのスクリプトが既定で実行されず、信頼したパッケージだけを明示的に許可する方向へ変更されています。ChainDropはpreinstallから自動実行されたため、この許可制は攻撃成立の範囲を狭めます。

ただし、インストールスクリプトが必要な正規パッケージも存在します。すべてを無条件に許可するのではなく、必要性を確認した上で許可リストを管理し、変更をコードレビューの対象にする必要があります。

  • 公開後の待機期間:新規バージョンを即時導入しない
  • ライフサイクル処理の許可制:実行が必要な依存パッケージを限定する
  • 推移的依存の可視化:SBOMとロックファイルで間接依存を追跡する
  • CI/CDの権限制限:ジョブごとに必要最小限のトークンとクラウド権限を付与する
  • ネットワーク送信制御:ビルドランナーからの外部通信先を制限・記録する
  • リリース承認:タグ作成や公開処理に複数人の承認と保護環境を要求する
  • 異常公開の監視:ソース変更を伴わないnpm公開や短時間の大量リリースを検知する

過去のnpm・開発環境サプライチェーン攻撃との関係

TKC Tech Labでは、2026年6月にRed Hat Cloud Services関連のnpm名前空間を侵害したMiasmaについて紹介しました。Miasmaもpreinstall、Bun、クラウド・CI/CD認証情報の窃取、Claude Code設定への永続化、自己増殖という共通点を持っています。

Red Hat系npm名前空間に「Miasma」ワーム——32パッケージ侵害

また、GitHub、npm、Visual Studio Codeを横断して認証情報とコード共有経路を悪用する攻撃として、GlasswormやClinejectionも取り上げています。

Glassworm再来——GitHub・npm・VS Codeの151超リポジトリに拡大
GitHub IssueからCline CLIの不正版が公開された「Clinejection」

ChainDropは、これまで個別に観測されてきたnpmトークン窃取、CI/CD侵害、AIコーディングツールへの永続化、自己増殖を一つの攻撃チェーンへ統合し、数時間で数百パッケージへ波及させました。

対象パッケージを安全なバージョンへ戻すだけでは対応は完了しません。悪意あるバージョンを実行した環境では、認証情報、リポジトリ、クラウド、ビルド成果物まで影響範囲を広げて確認することが重要です。

一次情報・公式情報

ChainDrop supply chain compromise: Anatomy of a self-propagating worm(Microsoft Security Research、2026年8月4日)
ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2(StepSecurity、2026年8月4日)
Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack(Socket、2026年8月4日)
Keyv and friends compromised in active Shai-Hulud supply chain attack(Aikido、2026年8月4日)
Upcoming breaking changes for npm v12(GitHub、2026年6月9日)
npm Config: min-release-age(npm Documentation)

参考情報

Massive ChainDrop npm supply-chain attack infects hundreds of packages(BleepingComputer、2026年8月4日)
Keyv-Linked npm Worm Poisons Hundreds of Packages(The Hacker News、2026年8月4日)

コメント

タイトルとURLをコピーしました