メンテナーアカウント侵害が疑われる中、悪意のあるnode-ipcのバージョンがnpmに公開

2026年5月14日、人気のnpmパッケージnode-ipcの複数の悪意あるバージョンがnpmレジストリに公開されました。現在の公開情報では、node-ipc@9.1.6、node-ipc@9.2.3、node-ipc@12.0.1が、難読化された認証情報窃取ペイロードを含む侵害バージョンとして特定されています。悪意あるコードはCommonJSバンドルのnode-ipc.cjsに追加され、パッケージがrequire("node-ipc")で読み込まれると実行されます。初期分析では、プロジェクトのCI/CDパイプラインが侵害されたのではなく、正規のnpmメンテナーアカウントが悪用された可能性が示されています。該当バージョンをインストールした、またはそれを使ってビルドした組織は、そうした環境からアクセス可能だった開発者、CI/CD、クラウド、SSH、GitHub、Kubernetesなどの認証情報や関連シークレットが漏えいした可能性があるものとして扱ってください。Snykは本件についてSNYK-JS-NODEIPC-16697063のアドバイザリを公開しています。脆弱な依存関係の経路を特定し、修正の優先順位を決める際にご活用ください。

関連コンポーネント

node-ipcはプロセス間通信に使用されるNode.jsパッケージで、npmエコシステム全体で直接・間接的に広く利用されてきました。

node-ipcがサプライチェーンインシデントに関与したのは、今回が初めてではありません。2022年には、抗議活動を目的としたソフトウェアのような挙動が下流の利用者に影響したnode-ipc／peacenotwarのインシデントを、Snykが分析しました。2026年5月の事案はこれとは別とみられます。現在の分析が示しているのは、抗議活動を目的としたソフトウェアではなく、難読化された認証情報窃取ペイロードを含む悪意あるバージョンです。

2026年のインシデントは、2022年のインシデントとは別の事案とみられます。現在報告されている2026年のペイロードは、2022年に確認された抗議活動を目的としたソフトウェアの挙動ではなく、認証情報の窃取と気づかれにくい外部送信を狙っています。公開分析によると、ペイロードはCommonJSのエントリーポイントに挿入されており、postinstallなどのnpmライフサイクルスクリプトには依存していません。

既知の影響バージョン

現在の公開情報では、これら3つのバージョンが悪意あるものとして特定されており、いずれも2026年5月14日に公開されたとされています。また、侵害されたnode-ipc.cjsファイルは、影響を受けたリリース間で同一だったとの報告もあります。

タイムライン

侵害が発生した経緯

最も有力な公開情報上の仮説は、正規の公開権限を持つnpmメンテナーアカウントを通じて、悪意あるバージョンが公開されたというものです。StepSecurityは、メンテナー一覧には掲載されていたものの、node-ipcの公開履歴がなかったatiertantアカウントからリリースが公開されたと報告しています。

Upwindをはじめとする公開情報では、期限切れドメインの乗っ取りにつながる可能性のある経路が説明されています。攻撃者がメンテナーアカウントのメールアドレスに関連するドメインを再登録し、メールを受信できるように設定した後、npmアカウントの復旧手続きを利用してアカウントを乗っ取った可能性があります。

現時点の証拠は、npmでの公開権限を持つメンテナーの身元が悪用されたことを示しています。公開分析では、期限切れのメンテナーのメールドメインがアカウント復旧を可能にした可能性が示唆されていますが、調査は続いています。この違いは重要です。npmレジストリ自体を侵害する必要はなく、プロジェクトのソースリポジトリやCI/CDパイプラインも初期の攻撃経路ではなかった可能性があるためです。

攻撃経路と悪意ある挙動

ペイロードは、require("node-ipc")でパッケージを読み込む利用者向けのCommonJSバンドル、node-ipc.cjsに挿入されたとみられます。公開分析によると、ESMのエントリーポイントは同様の変更を受けていません。

多くのnpmマルウェアインシデントとは異なり、今回の侵害ではpreinstall、install、postinstallなどのインストール時スクリプトは使われていなかったと報告されています。代わりに、悪意あるロジックは即時実行関数式として追加されていました。そのため、依存関係のインストール時だけでなく、実行時にパッケージをインポートした際にもコードが実行される可能性があります。

• 環境とホストのフィンガープリント取得

• ローカルの認証情報や開発者向け機密ファイルの検索

• クラウド認証情報、SSH鍵、Kubernetesトークン、GitHub CLI設定、Terraformの状態ファイル、データベース認証情報、シェル履歴、AI／開発者ツールの設定情報の収集

• 収集データの圧縮

• 攻撃者が管理するインフラへのデータ流出

StepSecurityによると、ペイロードは90種類以上の認証情報を標的とし、azurestaticprovider[.]netドメインを使用するインフラに収集データを外部送信しました。

影響を受ける可能性があるケース

1. プロジェクトがnode-ipcに直接依存しており、依存関係の解決結果が9.1.6、9.2.3、または12.0.1になっている。

2. プロジェクトが依存するパッケージの依存関係をたどると、該当バージョンが含まれている。

3. CI/CDパイプライン、コンテナビルド、開発者のワークステーション、またはパッケージキャッシュに、悪意あるバージョンがインストールされた。

4. ^9、~9.1、~9.2、^12などの広いsemver範囲やバージョンを固定しないインストールを使用しており、該当リリースが自動的に選択される可能性があった。

5. CommonJSによる解決を通じてnode-ipcを読み込むコードパスを実行した。

ロックファイルに該当バージョンが記載されていても、悪意あるコードが実行された証拠にはなりません。ただし、調査を開始するには十分です。シークレットにアクセス可能な開発者環境やCI/CD環境にパッケージがインストールされていた場合は、認証情報が漏えいした可能性があるものとして対応してください。

検出方法

プロジェクトのルートディレクトリでSnyk CLIを実行し、アプリケーションを確認してください。

snyk test

SnykのWeb UIでアプリケーションを監視している場合は、自動的に警告が表示されます。

それ以外の場合は、依存関係ツリーとロックファイルで該当バージョンを確認してください。

npm ls node-ipc

npm ls node-ipc --all 2>/dev/null | grep -E '9\.1\.6|9\.2\.3|12\.0\.1'

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec ls -lh {} \;

報告されているネットワークおよびホストの指標には、sh.azurestaticprovider[.]netへの外向き接続、37.16.75[.]69,への外向き通信、アプリケーションまたはビルドプロセスからの予期しないUDP/53通信、$TMPDIR/nt-*に一致する一時ディレクトリ、__ntw=1 環境フラグを使用するプロセスや子プロセスが含まれます。攻撃者のインフラが停止または変更されると、これらの指標も変化する可能性があります。そのため、該当する兆候が見つからなくても、安全の証明にはなりません。

緩和策と対応

悪意あるバージョンを削除する

• node-ipcを安全性が確認されたバージョンに固定します。

• ロックファイルを更新します。

• 悪意あるtarballが残っている可能性のあるローカルおよびCIのパッケージキャッシュを削除します。

• クリーンな依存関係ツリーからアーティファクトを再ビルドします。

パッケージがインストールされたすべての環境を特定する

• 開発者のノートPC

• CIランナー

• ビルドコンテナ

• 社内アーティファクトレジストリ

• 一時的なビルドワーカー

• 実行時にインポートされた場合は、本番システム

漏えいした可能性のあるシークレットをローテーションする

• npmトークン

• GitHubトークン

• クラウドプロバイダーの認証情報

• SSH鍵

• CI/CDシークレット

• Kubernetesトークンとkubeconfig

• データベース認証情報

• Terraformの状態ファイルへのアクセス認証情報

• AI／開発者ツールの認証情報

セッションを無効化し、アクセスログを確認する

• クラウドの監査ログを確認します。

• GitHub組織の監査ログを確認します。

• npmアカウントのアクティビティとパッケージの公開履歴を確認します。

• 不審なCI/CDジョブの挙動、新たなシークレットやデプロイキー、予期しないパッケージ公開がないか確認します。

パッケージ利用を強化する

• ロックファイルを使用し、再現性のあるビルドを行います。

• 本番ビルドシステムで、新たに公開されたパッケージバージョンを自動的に取り込まないようにします。

• 依存関係の更新にクールダウン期間を設けるか、社内パッケージプロキシのポリシーを導入します。

• npmのパッケージ公開者にMFAを義務付けます。

• オープンソースプロジェクトから、古いメンテナーや期限切れのメールドメインを削除します。

• メンテナーアカウントの変更や、長期間活動のなかった後の新たなリリースを監視します。

• Snykでアプリケーションを継続的にスキャン・監視し、脆弱性を検出しましょう

このインシデントが重要な理由

このインシデントは、オープンソースエコシステムを支える信頼関係を攻撃者が標的にする事例の一つです。悪意あるパッケージは、効果を発揮するためにアプリケーションの動作を妨げる必要はありませんでした。通常どおりの機能を維持しながら認証情報をひそかに収集することで、侵害されたビルドや開発環境が正常に稼働し続ける可能性を高めていました。

また、休眠状態またはメンテナンスがほとんど行われていないパッケージでも、長期間活動がない後に広範なエコシステムへの影響力を保ち続けるという、サプライチェーンにおける繰り返し見られる弱点も浮き彫りになりました。古いメンテナーの身元を復旧、乗っ取り、または悪用できれば、攻撃者はソース管理システムやCI/CDシステムに触れることなく、依存関係ツリーに悪意あるバージョンを公開できる可能性があります。

現時点での評価

入手可能な情報に基づき、本件は開発者およびCI/CD環境からの認証情報窃取を主なリスクとする、重大なnpmサプライチェーン侵害として扱う必要があります。現時点で確認されている影響バージョンは、node-ipc@9.1.6、node-ipc@9.2.3、node-ipc@12.0.1です。攻撃経路としては、公開権限を持つメンテナーアカウントの悪用が有力であり、期限切れのメンテナーのメールドメインを復旧した可能性もありますが、根本原因の調査は継続中です。

チームは、該当バージョンがインストールされていたかを直ちに確認し、影響を受けた環境のシークレットをローテーションするとともに、窃取された認証情報を使った二次的な不正行為を監視してください。