@antv npmに不正コード混入｜Mini Shai-HuludがAnt Design可視化323パッケージを22分で汚染

2026年5月19日 01:56 UTC、中国のAlibaba傘下Ant Designチームが管理するデータ可視化ライブラリ群 @antv のnpmメンテナアカウント atool が乗っ取られ、323パッケージ・639バージョンにMini Shai-Huludマルウェアが混入した。攻撃者はわずか22分間の自動化バーストで大量の悪性バージョンを公開し、週約110万ダウンロードを誇る echarts-for-react を含む多数の広く使われるパッケージを汚染した。悪性ペイロードはインストール時に自動実行され、AWS・GitHub・Kubernetes・Vault・SSH等20種類以上の認証情報を収集してC2サーバーへ暗号化送信する。

npmサプライチェーン攻撃全体の防御フレームワークと恒久対策についてはサプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリストをご覧ください。

1. 何が起きたか――22分間の自動化汚染バースト

時刻はすべてUTC。Socket Threat Research Teamの分析および各セキュリティベンダーの報告をもとに整理する。

今回の攻撃が従来のサプライチェーン攻撃と一線を画す点は「22分間の自動化バースト」にある。TanStack事件では6分間隔で2回のダブルタップパターンが観察されたが、@antv事件では1時間かけてほぼ全メンテナパッケージを網羅する自動化スクリプトが稼働した。639バージョンを1時間以内に公開するには人力ではまず不可能であり、攻撃者は事前に自動化ツールをセットアップしてatoolアカウントの乗っ取りを待っていたと考えられる。

攻撃を検知したSocketは、検知した339バージョンについて中央値6.7分という速さでアラートを発行した。しかし残念ながら、この6.7分の検知時間でも npm install を即座に走らせる多くのCI/CDパイプラインは感染した状態でビルドを完了させてしまった。

2. @antvとは何か――Ant Designを支えるデータ可視化エコシステム

@antv はAlibaba傘下のAnt Groupが開発・維持する大規模なデータ可視化ライブラリ群で、中国最大のエンタープライズUIシステム「Ant Design」と密接に統合されている。世界中の金融・BI・ダッシュボード系アプリケーションで使われており、そのダウンロード数は合計で週5000万を超える。

主要パッケージのスコープは以下の通りだ。

特筆すべきは echarts-for-react（週約110万DL）と timeago.js（週約150万DL）だ。どちらも atool アカウントが共同メンテナとして参加しており、@antv名前空間外のパッケージにも攻撃が波及した。今回の攻撃対象323パッケージのうち、@antv名前空間は直接的な標的であったが、@lint-md・@openclaw-cn・@starmind 等の関連名前空間パッケージも含まれている。

このエコシステムの規模が今回の攻撃を特に深刻なものにしている。@antv/g2やecharts-for-reactはReactエコシステムにおいて定番のグラフライブラリであり、「自分はTanStackを使っていないから安全だ」と判断していた多くのフロントエンド開発者・データエンジニアリングチームが今回の標的に含まれることになった。

3. 侵入経路と攻撃フロー――atoolアカウント乗っ取りからワーム化まで

攻撃の起点はnpmメンテナアカウント atool（メールアドレス: [email protected]）の乗っ取りだ。Socket・StepSecurityの分析によると、攻撃者はこのアカウントの認証情報を何らかの手段（クレデンシャルスタッフィング、フィッシング、または以前のデータ漏洩）で入手し、atoolが管理する全パッケージに一気にアクセス権を得た。

攻撃フロー全体を以下の図で示す。

Step 1 — アカウント乗っ取りと自動投稿

攻撃者はatoolアカウントの認証情報を使って npm Registry の API に直接アクセスし、自動化スクリプトで323パッケージの tarball を取得した後、各パッケージに悪性ペイロードを注入してバージョン番号を上げてから再公開した。この一連の作業が22分間で完了した。

Step 2 — preinstallフックによる実行

各悪性パッケージの package.json には "preinstall": "bun run index.js" というスクリプトフックが追加されている。npm install を実行した開発者・CIシステムはパッケージのインストール前にこのフックが自動的に発火する。Bunがインストールされていない環境ではペイロードが curl を使ってBunを自動インストールしてから実行する。

Step 3 — 難読化と認証情報収集

悪性の index.js は非常に高度に難読化されており、1728エントリの文字列配列ルックアップテーブルとPBKDF2シードのFisher-Yatesシャッフル・カスタム文字列暗号復号器を組み合わせている。静的解析ツールでは一見無害なコードに見える。実行時に復号されて130以上の認証情報ファイルパターンを順次スキャンし、見つかった認証情報を収集する。

Step 4 — 二重チャンネル流出

収集した認証情報はgzip圧縮後にAES-256-GCMで暗号化し、RSA-OAEPでAESキーをラップしてC2サーバー（t.m-kosche.com:443）に送信する。フォールバックとして、窃取したGitHubトークンを使って被害者アカウントに公開リポジトリを作成し、results/results-<timestamp>-<counter>.json に窃取データをコミットするデッドドロップ手法も用いる。作成されたリポジトリの説明文は niagA oG eW ereH :duluH-iahS（逆から読むと “Shai-Hulud: Here We Go Again”）という特徴的な文字列だ。

Step 5 — npm伝播（ワーム化）

攻撃の最も危険な側面がこのワーム化機能だ。ペイロードは窃取したnpmトークンを使ってnpm Registry APIでトークンを検証し、そのトークン所有者が管理する全パッケージを列挙する。次にそれらのパッケージのtarballをダウンロードして同一の悪性ペイロードを注入し、バージョン番号をインクリメントして再公開する。これにより攻撃の初期標的（@antv）を超えて、被害者自身の管理パッケージも感染源になってしまう。この機能によってSocket追跡では総計2200以上のGitHubリポジトリが既に窃取されたトークンで作成されていることが確認された。

4. ペイロードの破壊力――20種類以上の認証情報を根こそぎ盗む

悪性ペイロードが収集する認証情報は130以上のファイルパターンを対象としており、現代のクラウドネイティブ開発者が使うほぼすべての重要クレデンシャルを網羅している。

GitHub Actionsランナーメモリの読み取りはこの攻撃の特に注目すべき能力だ。StepSecurityの分析によると、ペイロードは /proc/[pid]/cmdline をスキャンして Runner.Worker プロセスを特定し、/proc/[pid]/mem 経由でプロセスメモリを直接読み取る。これによりGitHub Actionsがログにマスクして表示している *** 形式のシークレットでさえ、実際の値が流出する。この手法はGitHub Actionsの機密情報保護機能を完全に回避する。

対象とするCI/CDプラットフォームは10以上に上る。GitHub Actions・GitLab CI・Travis CI・CircleCI・Jenkins・Azure DevOps・AWS CodeBuildなど、現代の開発組織が使うほぼすべてのCI/CDシステムが標的だ。

收集した認証情報はAES-256-GCMで暗号化しRSA-OAEPでAESキーをラップした後、OpenTelemetryのAPIパスを模した https://t.m-kosche.com:443/api/public/otel/v1/traces に送信される。このエンドポイントのパスが正規の可観測性エンドポイントに偽装されているのは、ネットワーク監視ツールのシグネチャをかいくぐるためと考えられる。

5. 自分の環境が感染しているか確認する5ステップ

Step 1 — ロックファイルのスキャン

# package-lock.json / pnpm-lock.yaml / yarn.lock で対象パッケージを確認
grep -E '"@antv/|echarts-for-react|timeago\.js|size-sensor|canvas-nest' \
  package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

バージョン番号が確認できたら、Socketの公開IOCリスト（socket.dev/blog/antv-packages-compromised）と照合して悪性バージョンかどうかを確認する。原則として2026-05-19 01:56〜02:56 UTCの間に公開されたバージョンは疑うべきだ。

Step 2 — preinstallフックの検索

# node_modules内で悪性のpreinstallフックを持つpackage.jsonを検索
find node_modules -name "package.json" -not -path "*/node_modules/*/node_modules/*" \
  -exec grep -l '"preinstall".*"bun run index.js"' {} \;

# 大きな難読化index.jsを検索（400KB超はほぼ確実に悪性）
find node_modules -name "index.js" -size +400k -type f | head -20

Step 3 — GitHubデッドドロップリポジトリの確認

# GitHubに見覚えのない公開リポジトリが作られていないか確認
# GitHub CLIを使う場合
gh repo list --visibility public --json name,description | \
  grep -i "niagA\|Shai-Hulud\|sayyadina\|stillsuit"

# または gh api を直接叩く
gh api user/repos --paginate -q '.[] | select(.private == false) | [.name, .description] | @tsv' | \
  grep -i "shai"

Step 4 — ネットワーク接続ログの確認

CIログまたはホストのネットワークログで以下のドメインへの接続を確認する。

• t.m-kosche.com（C2サーバー、ポート443）
• 2026-05-19 01:56〜03:00 UTC の時間帯に実施したビルド・npm installと相関があるか

Step 5 — 永続化マーカーの確認

# 悪性ペイロードが置く永続化ファイルを確認
ls -la .claude/setup.mjs .vscode/setup.mjs 2>/dev/null
cat ~/.local/bin/gh-token-monitor.sh 2>/dev/null

# systemdユーザーサービスの確認（Linux）
systemctl --user list-units | grep monitor

# LaunchAgentの確認（macOS）
ls ~/Library/LaunchAgents/ | grep monitor

いずれかが発見された場合は後述の緊急対処手順を直ちに実施する。

6. 緊急対処手順――正しい順序で実施する

① 即座にCI/CDシークレットをローテーション

GitHub ActionsのシークレットをGitHub管理画面から更新する。AWS IAMアクセスキーを無効化して新しいキーを発行する。npm publish tokenを失効させて新しいトークンを生成する。Vault tokenをrevokeする。SSH鍵の場合は旧鍵を ~/.ssh/authorized_keys から削除してから新しい鍵ペアを生成する。

② 影響を受けたパッケージのダウングレード

package.json で影響を受けたバージョンを2026-05-19より前のクリーンバージョンに固定する。その後 npm install を実施するが、--ignore-scripts フラグを付けて実行する。

③ node_modulesの完全削除と再インストール

rm -rf node_modules package-lock.json
npm install --ignore-scripts

この際、.npmrc に ignore-scripts=true を追加しておくことで、次回以降のinstall時もpostinstallフックが実行されないようにする。

④ 永続化マーカーの削除

Step 5で見つかった永続化ファイルを削除する。systemdユーザーサービスは systemctl --user disable --now <service名> で無効化する。LaunchAgentは launchctl unload ~/Library/LaunchAgents/<plist名> で停止してからファイルを削除する。

⑤ GitHubの見覚えのない公開リポジトリを削除

デッドドロップとして作成されたリポジトリには実際の窃取データが含まれているため、速やかに削除する。ただし削除前にリポジトリの内容をダウンロードして、どの認証情報が流出したかを記録・確認しておくことを推奨する。

7. TanStack事件との比較――同一ワームの進化と拡大

Mini Shai-Huludワームは2026年5月11日のTanStack事件以来、わずか8日間でさらに大規模な攻撃へと進化した。以下の比較表で両事件の主要な違いを整理する。

最も重要な変化の一つは「BreachForumsでのソースコード公開」だ。Wiz Researchの分析によると、TeamPCPは@antv攻撃の前後にMini Shai-Huludのソースコード全体をBreachForumsで公開し、サプライチェーン攻撃コンテストを告知した。これは攻撃の「民主化」を意味し、今後は技術力の低い攻撃者でも同一手法でnpmサプライチェーン攻撃が実施できるようになる可能性を示している。

TanStack事件との比較詳細についてはTanStack公式@tanstack/*にマルウェア混入｜205パッケージに広がるMini Shai-Huludワームを参照してほしい。

また、npm名前空間を悪用したブランドスクワット型の攻撃パターンについては偽TanStackパッケージが.env窃取｜npmブランドスクワット攻撃の全容と緊急対策も参考になる。

8. 組織として今すぐやること――再発防止の恒久対策

1. preinstallフックのデフォルト無効化

CI/CDパイプラインの .npmrc に ignore-scripts=true を追加することがまず最初の一手だ。postinstall・preinstallフックは多くの攻撃の実行トリガーになっており、本当に必要なパッケージに対してのみ個別に許可するポリシーが望ましい。一方でネイティブモジュール（node-gyp 等）はbuildスクリプトが必要なケースも多いため、CI環境でのみこの設定を有効にするか、許可リスト方式を採用するかを組織の状況に合わせて判断する。

2. 依存関係スキャナをCIに組み込む

Socketはpackage.jsonの変更時に自動でPRコメントを追加するGitHub Appを提供している。Aikido SecurityはCI内でリアルタイムスキャンを実施する。どちらも npm install を実行する前に悪性シグナルを検出でき、今回の事件のように6〜7分で検知が可能になる。

3. npm 2FAの全メンテナへの強制

今回の攻撃の根本原因はメンテナアカウントの乗っ取りだ。npm Registry の組織設定で、パッケージの publish には 2FAを必須とするポリシーを設定する。npm本体も2023年以降、一定の基準を満たすパッケージに対してトラステッドパブリッシャー（GitHub Actions OIDC）への移行を推奨しているが、今回の事件のようにメンテナが複数いるエコシステムではすべてのメンテナのアカウントセキュリティを管理することが難しい。

4. lock ファイルのCI検証とdependency review

GitHub Actionsの dependency-review ワークフローを追加することで、PRがマージされる前に依存関係の変化を自動検知できる。またPR時にlock ファイルのdiffを必ずレビューするルールを設けることも有効だ。攻撃者は package.json への直接変更を最小化して lock ファイルレベルでの変化を狙うケースがあるため、lock ファイルのdiff確認が重要になる。

5. ネットワークレベルでのC2ドメインブロック

今回判明したC2ドメイン t.m-kosche.com をファイアウォールまたはDNSフィルタリングでブロックする。ただしこれはすでに感染した環境での流出防止であり、感染そのものの予防にはならない点に留意が必要だ。GitHubデッドドロップについては、GitHubそのものをブロックするわけにはいかないため、GitHubトークンのスコープを最小化して意図しないリポジトリ作成ができないようにする（repo スコープの代わりに読み取り専用スコープ read:user のみ付与する等）。

6. CI/CDパイプラインのランナーメモリ保護

今回のペイロードはGitHub Actionsランナーの /proc/[pid]/mem を読み取ってマスクされたシークレットを窃取する。StepSecurityのHarden-Runnerを使うと、このようなプロセスメモリ読み取りをブロックすることができる。また seccomp プロファイルでプロセス間メモリ読み取りシステムコール（ptrace・process_vm_readv等）を制限するのも効果的だ。

CI/CDパイプラインのセキュリティ強化全般についてはAI自動化ツール完全ガイド2026｜導入から本番運用までのDevOpsセキュリティセクションも参考にしてほしい。

9. 攻撃者帰属――TeamPCPとBreachForumsコンテストの深刻な含意

Wiz Researchは中程度の確信度でこの攻撃活動を脅威アクター「TeamPCP」に帰属させている。帰属の根拠はインフラストラクチャの重複（C2ドメインの使い回し）、マルウェア機能の一致、オペレーション上のパターン、および過去のTanStack事件との手法的な連続性だ。

TeamPCPは金銭目的の動機を持つ脅威アクターとして追跡されており、窃取した認証情報をダークウェブマーケットで販売するか、直接的なクラウドリソースの不正使用に転換すると考えられている。AWSクレデンシャルが一つでも流出すれば、不正なEC2インスタンスを大量に起動して暗号通貨マイニングに使用するといった手法で直接的な金銭的利益を得ることができる。

特に深刻なのは「攻撃のオープンソース化」だ。Mini Shai-Huludのソースコードが公開されたことで、この攻撃パターンが一部の脅威アクターだけのものではなくなった。BreachForumsでのコンテスト告知は「最も多くのパッケージを汚染できた参加者に賞金を出す」という形式だったとWizの分析では言及されており、今後この攻撃手法を使う主体が増えることが予測される。これはnpmエコシステム全体として対処を迫られる問題だ。

まとめ

今回の事件は、メンテナアカウントのセキュリティという根本的な弱点を突いたものだ。コード署名・npm provenanceがあっても「正規のメンテナのアカウントが乗っ取られた」場合には無力であることが改めて示された。npmエコシステム全体として、メンテナアカウントへの2FA強制・ハードウェアキー必須化・アカウント監視の仕組みを強化することが急務となっている。

参照ソース

• Socket Threat Research — Active Supply Chain Attack Compromises @antv Packages on npm
• StepSecurity — Shai-Hulud: Here We Go Again. Mass npm Supply Chain Attack Hits the AntV Ecosystem
• Wiz Research — The Worm That Keeps on Digging: TeamPCP Hits @antv in Latest Wave
• OX Security — The @antv Ecosystem Was Compromised with Shai-Hulud Malware, 300+ Packages Affected
• SafeDep — Mini Shai-Hulud Strikes Again: 317 npm Packages Compromised