ハクソク

世界を動かす技術を、日本語で。

ミニ・シャイ・フルードが再び襲来：314のnpmパッケージが侵害される

7日前原文(safedep.io)

概要

  • 2026年5月19日、 npmアカウント atool が 大規模に侵害 され、317パッケージに637の悪意あるバージョンが公開
  • 主要パッケージ （size-sensor、echarts-for-react等）が自動化された攻撃で汚染
  • Mini Shai-Huludツールキット 利用、 認証情報収集と二重流出経路 を実装
  • CI/CD環境・AIエージェント・VS Code などにも永続化を仕込む
  • 脅威の指標（IoC） と 影響範囲、 検知・防御策 について解説

npm atoolアカウント侵害の全貌

  • 2026年5月19日、 atool([email protected]) のnpmアカウントが 攻撃者に乗っ取られ、22分間で 637の悪意あるバージョン が 317パッケージ に自動公開
  • 被害パッケージ例：
    • size-sensor （月間4.2Mダウンロード）
    • echarts-for-react （3.8M）
    • @antv/scale （2.2M）
    • timeago.js （1.15M）
    • @antv系パッケージ 多数
  • payload は 498KBの難読化Bunスクリプト、SAP事案で使われた Mini Shai-Hulud と同一構造

攻撃フロー

  • preinstallフック （bun run index.js）でpayload実行
  • optionalDependencies で GitHub imposterコミット から二重にpayload配布
    • antvis/G2リポジトリ の孤立コミットを利用、正規コミット履歴には現れない
    • npm github:依存解決 の仕様を悪用し、SHA指定でpayload取得・実行

収集・流出対象

  • AWS認証情報 （env/config/EC2/ECS/SecretsManager）
  • Kubernetesサービスアカウントトークン
  • HashiCorp Vault・GitHub PAT・npmトークン・SSH鍵
  • ローカルパスワードマネージャ（1Password/Bitwarden/pass/gopass）
  • GCP/Azure/DB/Stripe/Slack/Docker認証情報
  • CI/CDのOIDCトークン交換・Sigstore署名 で 正規署名アーティファクト も生成

データ流出経路

  • 2系統の並列流出：
    • GitHubパブリックリポジトリ へのGitオブジェクトコミット
      • User-Agent: python-requests/2.31.0
      • Duneシリーズ由来の命名パターン のリポジトリ
    • RSA+AES暗号化HTTPS POST （OpenTelemetryトレース偽装）
      • t.m-kosche[.]com/api/public/otel/v1/traces

永続化・拡散

  • .github/workflows/codeql.yml へ「Run Copilot」ワークフロー注入
    • secretsダンプ→アーティファクト化→自己削除
  • Claude Code/Codex/VS Code に SessionStart/タスクフック を仕込み再感染
  • systemd/macOS LaunchAgent で kitty-monitorサービス 設置
    • GitHub dead-drop C2 （commitメッセージ署名コマンドで遠隔操作）
  • gh-token-monitor で GitHubトークンを60秒ごと監視
  • Dockerソケット経由でホスト脱出・他Node.jsプロジェクトへ拡散

IoC（侵害指標）

  • 2026-05-19 01:44〜02:06 UTC に atool が公開した全パッケージ
  • preinstall script: bun run index.js
  • Payload SHA256: a68dd1e6a6e35ec3771e1f94fe796f55dfe65a2b94560516ff4ac189390dfa1c
  • antvis/G2 の孤立コミット（例：1916faa365f2788b6e193514872d51a242876569）
  • optionalDependencies: @antv/setup: github:antvis/G2#<commit-sha>
  • exfilリポジトリ命名: {word1}-{word2}-{number}（Dune語句組み合わせ）
  • HTTPS exfil: t.m-kosche[.]com/api/public/otel/v1/traces
  • EC2/ECSメタデータへのHTTPリクエスト
  • chore/add-codeql-static-analysis ブランチ
  • .github/workflows/codeql.yml （Run Copilot名）
  • claude/settings.json /VS Code tasks.jsonへのフック
  • kitty-monitor/gh-token-monitor/cat.py 等のファイル

影響範囲とリスク

  • semver範囲指定（例：^3.0.6） のプロジェクトは 自動的に汚染バージョンを解決
  • CI/CD・AIエージェント・VS Code など 多様な環境で再感染・永続化
  • 正規署名付きアーティファクト も作成され、 検知困難

防御・検知策

  • 侵害期間中のatoolパッケージ利用停止・ロックファイル監査
  • pmg(Package Manager Guard) 等の インストールプロキシ で burst公開対策
  • .github/workflows/codeql.yml 等のワークフロー・設定ファイル監査
  • 永続化プロセス・ファイル（kitty-monitor等） の有無チェック
  • GitHubリポジトリ・コミットメッセージ監査（firedalazer等）
  • CI/CD・開発環境の認証情報再発行・ローテーション

まとめ

  • npmサプライチェーン攻撃の最新手法 が高度化し、 認証情報流出・永続化・再感染 の複合攻撃が現実化
  • 攻撃者はnpmの仕様・GitHubの運用・CI/CDの脆弱性を多層的に悪用
  • 開発者・運用者は依存パッケージ管理・CI/CD監査・認証情報管理の強化が急務

Hackerたちの意見

もう「Mr. Bones' Wild Ride」から降りたい気分なんだけど、これからも続きそうで心配。自分の調査によると、商業的な検出戦略の多くは、パッケージを読み込んだり使ったりする際に、リポジトリやデバイス、開発者レベルに向けられてるみたい。これは、メールのスパムや一般的なマルウェアへの対処法に似てると思う。つまり、悪意のある人たちが狙う価値のあるターゲットがほぼ常に存在するってこと。でも、メールとは違って（ほとんどの場合）、パッケージマネージャーは中央集権的な権威だし、何か外部からの問題は開発者の責任だよね？私の無知な感覚だけど、急速なリリースによる怠惰なバージョニングの文化を変えて、安定した、しっかりスキャンされたバージョンに焦点を当てる必要があるかもしれない。量やスケールの影響もあるだろうから、私の考えが間違ってるかもしれないけど、高い回転率の言語に影響が出やすいのは示唆的だよね。よくわからないけど、今の状況を詳しく探る包括的な記事があったらいいな。

└

「Mr. Bones' Wild Ride」について気になって、1991年の映画「Nothing But Trouble」を思い出したんだけど、実際には間違えて覚えてた。あの映画のジェットコースターは「Mr. Bonestripper」って名前だった。https://www.youtube.com/watch?v=NEZEgd8GjJc それとは別に、「Roller Coaster Tycoon 2」から来てるんだ。https://knowyourmeme.com/memes/mr-bones-wild-ride スパムとの比較についてだけど、結局、ほとんどの商業的・社会的なコンピューターネットワークの設定で、メールアドレスを吸い上げて人々にスパムを受け入れさせるような形になってるよね。これもこの分野で起こる可能性が高いと思う。たぶん、Oracleのライセンス監視エージェントスタイルのソフトウェアと自動依存関係管理の組み合わせで、サプライチェーンのマルウェアをホワイトリスト化することで「解決」するみたいな。

状況がマジでクレイジーになってきてる…個人的には、すでにノードやPython、パッケージマネージャーを全部アンインストールして、今はdevcontainersやVMだけで使ってる。でも、たとえ開発コミュニティが超ハードなセキュリティを考え出しても、少なくとも1年後には、ソーシャルエンジニアリングのモデルが十分に良くなって、結局負け続けるゲームをしてる気がする。

└

コンテナはどうやって問題を解決するの？もしインターネットに接続されてるなら（もちろん接続されてる）、同じ問題があると思う。コンテナが認証情報を読み取れるなら、少なくとも私の理解ではそうだよ。

└

ノードなしで、どうやってクラウドリソースを管理するの？Cloudflareはwranglerが必要だし、AWSにはたくさんのノードCLIがあるよね。などなど。

Dockerコンテナのエスケープ > ペイロードはDockerソケットをチェックして、もしあれば、3つの連続した方法でコンテナエスケープを試みる。だから、devcontainersやVMを使っていても、これらのワームはすでに脱出を試みてるよ。ルートレスのVMエンジン（例えば、Dockerの代わりにPodman）を使ってるか確認してね！

└

ルートレスのVMエンジン（例えば、Dockerの代わりにPodman）を使ってるか確認してね！ ほとんどの人はLinuxでDockerをルートレスで使ってるんじゃないの？Podmanはもっと何かしてるの？

└

それとも、Dockerソケットをコンテナにマウントしない方がいいよ。

└

本当に、もっと「jails」や「zones」のようなものがあればよかったな。あるいは、コンテナをjailやzoneに入れるのがベストだね。BSDみたいに、Linux用の包括的なサンドボックスってあるのかな？

└

オープンコードには、エージェントに本当にガードレールを設けるプロトコルがあればいいのに。移植を試みるより、SSHが何十年もあるんだから、逸脱しないコミュニケーション経路を構築できるはずだよね。

└

podmanが設定でルートレスになっているか確認するには、次のコマンドを実行してみてね：> podman info --format '{{.Host.Security.Rootless}}'

└

ちゃんとした仮想マシンを使ったらどう？

└

一部の人が言うこととは裏腹に（セキュリティ業界の多くの人も含めて）、Dockerは強力なセキュリティ境界ではなく、そう扱うべきではないよ。実行中のシステムとカーネルを共有しているからね。昔の低権限のLinuxアカウントを配って、カーネルに権限昇格を防がせていた頃を思い出すよ。Dockerは文字通り同じことをしているだけで、ただ手順が増えただけ。特に今は新しいカーネルのLPEが5分ごとに出てきているからね。確かにPodmanは少しマシだけど、攻撃者にルートを渡すわけじゃないけど…それでもアカウントを渡す必要があるの？ちゃんとしたVMを使えばいいのに。

└

自分の「devcontainers」にはpodmanを使ってるよ： https://github.com/evertheylen/probox。もし誰か、俺のセットアップの弱点を指摘してくれたら嬉しいな！

これが、私の開発マシンがRaspberry Piで、SDカードを外すだけでいつでもイメージできる理由の一部だよ： https://blog.jgc.org/2026/04/raspberry-pi-as-isolated-ai-cod...

└

それは素晴らしいけど、開発マシンに機密データ、例えば認証情報を保存してるんじゃないの？これじゃ一番重要じゃない「侵害後にOSを再インストールする」ステップしか解決できないよ。

あまり推奨されていない解決策の一つは、すべてのアップグレードの差分を明示的に監査するClaudeの指示やスキルを持つことだね。この手動監査をアップグレードのワークフローの一部にするのがいいと思う。かなり信頼性がありそう。

└

これは、多くのAIサプライチェーンセキュリティスタートアップ（この記事を投稿したところのような）が、すでにすべてのNPMパッケージに対して行っていることだから、Claudeトークンを無駄にしないで。これらの妥協は数分以内に検出されたけど、NPMが影響を受けたパッケージをすべて非公開にするには少し時間がかかる（1時間未満）。

└

超バカな質問かもしれないけど、2023年から何らかのAIを使って開発してる者として聞きたい。外部コードのAI監査ってどう役立つの？悪意のある変更を無視するようにプロンプトを注入されることはないの？正直、薄っぺらいレイヤーだと思ってて、「プロンプト注入を許可しない」って言っても、「ミスをするな」って言ってるようなもんじゃん。確か、systemとuserレベルのメッセージには優先順位があったと思うから、特別に作られたツールには独自のシステムプロンプトがあれば注入を防げるはず。でも、Claude CLIに聞くとプロンプト注入が許されるかもしれない。どう思う？経験談も聞きたいな。

「これを防ぐ方法はない」と言う、これが定期的に起こる唯一の開発コミュニティ — https://itnext.io/no-way-to-prevent-this-says-only-developme...>

└

「適切に管理されたサプライチェーンは、オープンなインターネットの自由に必要であり、開発者が数百の未検査の遷移依存関係を保持する権利は侵害されてはならない。」

└

ノードエコシステムは、社会的およびソフトウェア設計の理由から、確かにより脆弱だよ。でも、PyPIやCargoなども根本的にはそれほど脆弱じゃないってことを人々は認識する必要がある。そこでも同じことが起こるから。

└

これって「Macにはウイルスがない」みたいなシナリオじゃない？

└

「これが定期的に起こるのは開発コミュニティだけだと言ってるけど、他の場所でもそんな問題があったよ… Shai-HuludがMavenに入ったり、PHP Composerにも入ったり、typosquattersがMavenに入り込んだりしてるし、これは新しいことじゃないんだよね。スキディからは誰も安全じゃないし、国家の行為者からもね。」

└

笑えるけど、npmだけがこういうことが定期的に起こる開発コミュニティじゃないよ。このジョークが言及してるOnionの記事[1]は面白いけど、アメリカが人口あたりの銃の死亡者数が圧倒的に多い理由が非常に明確で obvious だからね。これはnpmには当てはまらないよ。

└

NPMはその人気とエコシステムの不確実性のために、常に攻撃者の主要なターゲットになるし、人々（メンテナー）は常に弱点になるんだよね。

└

こういう言語専用のパッケージマネージャーはセキュリティの悪夢だけど、npmは本当に下手くそなことをやってるから、なんか不安定なものを求めてる気がする。

└

「これを防ぐ方法はない」っていうアナロジーは、メモリ安全性の方がしっくりくると思う。銃の安全性と同じで、問題を解決する方法はみんな知ってるのに、一部の人たちは不可能だって言い張る。こういう時に「実際、コピー＆ペーストの方がいい」って言ってる人たちが騒ぐけど、いざ自分たちの番になると耳を塞いじゃう。メモリ安全性や銃の安全性の問題が本当の問題なんだ。もしShai-Huludが君が使ってるOdinリリースに入ってきたら、君のソフトウェアが台無しになるし、君の「ベンダーすべて」C++プロジェクトにコピー＆ペーストされたら、オートメーションを使わない選択をしたからって問題が解決したわけじゃないよ。

npmやGitHubがこの攻撃を軽減するために何かアクションを起こすのが待ちきれないよ。本当に何でもいいから。ポストインストールスクリプトの文字列に対して基本的なWAFスタイルのブロックを考えたことある？公開時にLLMを使ったコードスキャンとか。誰かいるの？いや、いないんじゃないかな。

└

第三者が侵害されたパッケージを検出できるのに、Microsoftができないのはおかしいよね。

エコシステム全体に関して：TC39はJS自体により良い標準ライブラリを追加することを検討すべきだと思う。それによってワンライナーのパッケージの数が減るはず。俺も同意するよ、Denoを使っていた頃の一番の魅力はその標準ライブラリと全体的に完璧な開発環境だった。ランタイムには統合されたテストランナーとアサーションライブラリが付いてくるのが当たり前だよね。0 - https://docs.deno.com/runtime/reference/std/

ある時点で、Dependabotをオフにして、すべてのNPMパッケージ（マイナー/パッチバージョンも含めて）を凍結する方が、継続的に更新するよりいいんじゃないかな？特にフロントエンドのパッケージに関しては、最近は意味のあるセキュリティ修正よりもサプライチェーン攻撃の方が多い気がする。確かに悲しい状況だけど、フロントエンドを静的BOMに切り替えて、少なくともNPMが「古いバージョンには再公開できない」という最低限の制約を守ってくれると信じられない理由はないよね？

└

そうだね。これが他のエコシステムでサプライチェーン攻撃が少ない理由の一部でもある。

zedが1.0になったから全力で行きたいけど、セキュリティモデルは全か無かなんだよね。つまり、知らないNPMパッケージをいつでもダウンロードしてインストールするのを許可するか、すべてのLSP機能をオフにするかのどちらか。で、こんなニュースを見続けるわけ。