npmサプライチェーン攻撃、IronWormが36パッケージを汚染

ソフトウェアサプライチェーンを標的とした新たな攻撃が表面化した。サプライチェーン・DevOps企業のJFrogが6月4日に報告したところによると、IronWormと名付けられたRust製の情報窃取型マルウェアが、npmレジストリ上の36のパッケージに感染していることが確認された。

この攻撃は、開発者やCI（継続的インテグレーション）環境を狙い、認証情報を窃取した上で、自ら感染を拡大する高度な手口を備えている。BleepingComputerの報道を基に、その実態を詳報する。

攻撃の全体像

JFrogの研究者が発見したIronWormは、単なるパッケージの汚染にとどまらない多層的な攻撃である。BleepingComputerの記事によれば、このマルウェアは 86の環境変数（キーと値のペア）と20の認証情報ファイル を標的にする。

標的となるのは、OpenAI、AWS、Anthropic、npmの認証情報のほか、Vault設定ファイル、SSHキー、Exodus暗号通貨ウォレットのファイルだ。昨今のAIブームを反映し、OpenAIやAnthropicといったAIサービスのAPIキーが標的に含まれている点が特徴的と言える。

RustとeBPFがもたらす脅威

IronWormの技術的な特徴は、その実装言語と隠蔽手法にある。

Rustによるクロスプラットフォーム性

マルウェア本体はRustで記述されている。Rustはメモリ安全性が高く、性能も優れているため、近年注目を集める言語だが、この特性が攻撃者にとってもメリットになった形だ。クロスプラットフォームでの動作が比較的容易であり、LinuxやmacOS、Windowsなど多様な開発環境への展開が想定される。

eBPFルートキットによる隠蔽

さらにIronWormは、eBPF（extended Berkeley Packet Filter） を利用したカーネルレベルのルートキットの背後に潜伏する。eBPFは本来、Linuxカーネルの動作を安全に拡張するための技術だが、悪用することでプロセスやネットワーク通信をカーネルレベルで隠蔽できる。これにより、通常のユーザー空間で動作するセキュリティツールによる検出が難しくなる。

Torネットワークでの通信

マルウェアと攻撃者のC2（コマンド＆コントロール）サーバーとの通信は、Torネットワークを経由して行われる。Torを使うことで発信元のIPアドレスが隠蔽され、追跡が困難になる。通信内容も暗号化されているとみられ、ネットワーク監視によるC2サーバーの特定も難しい。

自己増殖という賢い設計

IronWormの最も危険な側面は、その自己増殖能力にある。

npmのTrusted Publishingを悪用

マルウェアは、npmに公開するための認証情報を窃取する。この際、npmが推奨するTrusted Publishingワークフローに関連するシークレットも標的に含まれる。Trusted Publishingは、OIDC（OpenID Connect）を利用してCI/CDパイプラインから直接npmに公開する仕組みだが、このトークンが奪われると、正規の開発者としてパッケージを公開できるようになる。

感染の連鎖

開発者やCI環境が侵害されると、IronWormは被害者のnpmアカウントを用いて、トロイの木馬化されたバージョンのパッケージを公開する。これを別の開発者がインストールすれば、その環境も感染する――という連鎖が発生する。BleepingComputerの記事では、これを 「サプライチェーンにおけるウイルス感染の連鎖」 と表現している。

Shai Huludとの関連性

この攻撃と類似性を持つのが、最近GitHubでコードが公開されたShai Huludと呼ばれるマルウェアだ。JFrogの研究者は両者に直接的な関連性を見出していないものの、両方の攻撃で同じコミット名が使われている ことを確認している。

このことから、IronWormはTeamPCPと呼ばれるグループのペイロードの進化版である可能性がある。TeamPCPは過去にもnpmやPyPIを狙ったサプライチェーン攻撃を行ってきたことで知られるグループだ。Researchによると、IronWormは 「独自のインフラを持つ組織による、カスタムで慎重に構築されたインプラント」 であり、単なるスクリプトキディの遊びではないことがうかがえる。

感染範囲と可視化されたパッケージ

JFrogは報告書の中で、影響を受けたパッケージ名とバージョンの全リストを公開している。開発者は自分が使用しているパッケージがリストに含まれていないか、至急確認する必要がある。

同時に、Endor LabsとStepSecurityは、同じ時期に展開された別の攻撃を確認している。こちらはbinding.gypというJavaScriptベースのマルウェアであり、レジストリポイズニングとGitHub Actionsの感染を狙うものだ。IronWormとは別の攻撃だが、時期が重なっており、npmエコシステムが多面的な攻撃にさらされている現状が浮き彫りになった。

開発者が取るべき対策

今回の攻撃を受けて、開発者および組織は以下の対策を直ちに実施すべきだと、JFrogは推奨している。

JFrogの報告書では、影響を受けた全パッケージ名とそのバージョンがリスト化されて提供されている。開発者はこのリストを確認し、該当するパッケージがプロジェクト内で使用されていないか精査する必要がある。

修正版へのアップグレード

影響を受けたパッケージの多くは、既に修正版が公開されている。プロジェクトの依存関係を最新の安全なバージョンに更新し、ロックファイル（package-lock.jsonやyarn.lock）も再生成することが第一歩となる。

認証情報のローテーション

IronWormの標的はOpenAI、AWS、Anthropicといったサービスの認証情報であるため、これらのキーが流出した可能性がある。該当する可能性がある認証情報は、すべて新しいものに変更（ローテーション）する必要がある。特にCI/CDパイプラインで使っているトークンやシークレットは、漏洩の有無にかかわらず交換が推奨される。

多要素認証（2FA）の有効化

npmアカウントを含むすべてのアカウントに対して、多要素認証を有効にすべきだ。2FAが有効であれば、たとえパスワードやトークンが漏洩しても、アカウントへの不正アクセスを防げる可能性が高まる。

CI環境の監査

パッケージ公開に使用しているCI/CDパイプライン（GitHub Actions、GitLab CI/CD、CircleCIなど）を確認し、不要な権限が付与されていないかを監査する。特にTrusted Publishingを使っている場合、そのトークンがどのような経路で管理されているかを再確認する価値がある。

編集部の見解

短期的影響: 今回のIronWorm攻撃は、npmエコシステムに差し迫った影響を与えている。36ものパッケージが汚染され、その中には人気のパッケージも含まれている可能性があるため、影響範囲は当初の想定より広いかもしれない。今後数週間のうちに、これらのパッケージに依存するアプリケーションから悪意あるコードが削除される修正版のリリースラッシュが起きるだろう。また、eBPFルートキットという比較的新しい技術がサプライチェーン攻撃に使われたことで、セキュリティベンダーはeBPFベースのマルウェア検出手法の開発を急がざるを得なくなる。組織内で使用しているパッケージのスキャンと依存関係の見直しは、直ちに実行すべき喫緊のタスクだ。

長期的視点: この事件は、ソフトウェアサプライチェーンの信頼性に根本的な疑問を投げかけている。従来のパッケージマネージャーとCI/CDパイプラインの連携は生産性向上に貢献してきたが、Trusted Publishingのような便利な機能が逆に攻撃者の侵入口になっている。今後1～2年のうちに、パッケージの署名や公開プロセスの厳格化、npm以外の代替レジストリの台頭、あるいはRust製のセキュリティツールの普及といった流れが加速する可能性がある。また、AIサービスのAPIキーが標的になったことは、多くのスタートアップや大企業が自社のAI資産を守るための新たな認証管理ポリシーを導入する契機となるだろう。

編集部からの問い: 今回の事件で気になるのは、36ものパッケージが同時に汚染された一方で、それらが「誰によって」作成され、なぜ「どのような目的で」長期間検出されなかったのか、という点だ。また、IronWormがShai Huludと同じコミット名を使っているという手がかりはあるが、両者の直接的な関係は明らかではない。コミュニティとしては、これらのマルウェアが同一の脅威アクターによるものか、それとも異なるグループが類似の手法を模倣しているのか、明確な理解を得る必要がある。読者には、自社のCI/CDパイプラインの監視強化や、パッケージ公開プロセスに多層的な検証を導入するなどの予防策を検討することをお勧めしたい。

参考

• Slashdot: New IronWorm Malware Hits 36 Packages In npm Supply-Chain Attack — 2026-06-04公開
• BleepingComputer（JFrogの報告に基づく報道）
• JFrog公式ブログ（影響を受けたパッケージリストを含む報告書）