Axios npmパッケージが侵害：サプライチェーン攻撃でクロスプラットフォームRATを配布

2026年3月31日、週あたり1億回以上ダウンロードされる非常に人気の高いJavaScript HTTPクライアントaxiosの悪意あるバージョン2つが、侵害されたメンテナーアカウントを通じて一時的にnpmに公開されました。このパッケージには隠された依存関係が含まれており、2時間の公開期間中にnpm install（またはBunなど他のパッケージマネージャーでの同等のコマンド）を実行したマシンに、クロスプラットフォーム対応のリモートアクセス型トロイの木馬（RAT）を展開しました。

悪意あるバージョン（1.14.1、0.30.4）は03:29 UTCまでにnpmから削除されました。しかし公開期間中に、CI/CDパイプライン、開発環境、ビルドシステムで新規インストールを実行した場合、Axiosのコードに一切触れていなくても侵害されている可能性があります。

要点

攻撃の手口

これは、タイポスクワッティングされたパッケージや、悪意ある依存関係がビルドに紛れ込んだケースではありません。攻撃者はnpm上の公式axiosパッケージへの直接的な公開権限を持っていた（または取得した）とみられ、メンテナーのアカウントが侵害された可能性が高いです。公式GitHubのイシュースレッドに投稿した共同作業者によると、侵害されたと疑われるアカウントはメンテナーの@jasonsaaymanのもので、他の共同作業者より高いリポジトリ権限を持っていたため、迅速な対応が難しくなりました。

攻撃者はAxiosのソースファイルを直接変更していません。代わりに、新しいaxiosリリースのpackage.jsonに、あらかじめ準備されていた悪意ある依存関係plain-crypto-js@4.2.1を追加しました。plain-crypto-jsパッケージ自体がこの攻撃のために作られたもので、18時間前には「クリーン」な旧バージョン（4.2.0）が公開されていました。これはレジストリ上に短い公開履歴を作るためだったと考えられます。バージョン4.2.1には悪意あるペイロードが含まれていました。

開発者またはCIシステムがnpm install axios@1.14.1を実行すると、npmは依存関係ツリーを解決してplain-crypto-js@4.2.1を取得し、そのpostinstallフックであるnode setup.jsを自動実行します。このスクリプトの実行をきっかけに侵害が始まります。

ドロッパー：二重に難読化され、実行後に自ら消去

setup.jsのpostinstallドロッパーは、静的解析を回避するために2段階の難読化を施しています。

1. パディング文字を置換した逆順のBase64エンコード

2. キーOrDeR_7077と定数333を使ったXOR暗号

難読化を解除すると、スクリプトはos.platform()でホストOSを検出し、C2サーバーsfrclak[.]com:8000（IPアドレス：142.11.206.73）に接続して、プラットフォームに応じた第2段階のペイロードをダウンロードします。

実行後、マルウェアは痕跡を消去します。setup.jsを削除し、postinstallフックを含むpackage.jsonを取り除いて、クリーンなpackage.mdをpackage.jsonに改名して置き換えます。実行後にnode_modules/plain-crypto-jsを調べても、postinstallスクリプトが存在していた明らかな痕跡は見つかりません。

プラットフォーム別のペイロード

第2段階のペイロードは各プラットフォームに合わせて作られています。

macOS

AppleScriptが/Library/Caches/com.apple.act.mondにバイナリをダウンロードします。Appleのバックグラウンドデーモンの命名規則を意図的にまねて、目立たないようにしています。侵入後、RATは次の動作を行います。

• 16文字の一意な被害者IDを生成する

• ホスト名、ユーザー名、macOSのバージョン、起動・インストール時刻、CPUアーキテクチャ（mac_armまたはmac_x64）、実行中のプロセスなど、システム情報を収集する

• 偽装したIE8/Windows XPのUser-Agent文字列を使い、60秒ごとにC2サーバーへビーコンを送信する

• 攻撃者から4種類のコマンドを受け付ける：

  • peinject：C2からBase64エンコードされたバイナリを受信してデコードし、隠し一時ファイル（例：/private/tmp/.XXXXXX）に書き込みます。codesign --force --deep --sign -でアドホック署名を行ってGatekeeperを回避し、実行します。

  • runscript：/bin/shを介して任意のシェルコマンドを実行するか、osascriptでAppleScriptファイルを実行する

  • rundir：/Applications, ~/Library、~/Application Supportのファイルシステムメタデータを列挙する

  • kill：RATプロセスを終了する

Windows

VBScriptダウンローダーがPowerShellバイナリを%PROGRAMDATA%\wt.exe（Windows Terminalを装うファイル名）にコピーし、実行ポリシーのバイパスフラグを指定して、非表示のPowerShell RATを実行します。

Linux

Python製RATが/tmp/ld.pyにダウンロードされ、nohup python3で孤立したバックグラウンドプロセスとして起動します。これにより、起動元のターミナルセッションから切り離されます。

その他の侵害されたパッケージ

悪意あるplain-crypto-js依存関係を含む、他の2つのパッケージも確認されています。

• @qqbrowser/openclaw-qbot@0.0.130 — 改ざんされたaxios@1.14.1を含み、依存関係が注入されています（SNYK-JS-QQBROWSEROPENCLAWQBOT-15850776）

• @shadanai/openclaw（バージョン2026.3.31-1、2026.3.31-2）— plain-crypto-jsを直接同梱しています（SNYK-JS-SHADANAIOPENCLAW-15850775）

これらの二次的なパッケージは、攻撃者のインフラが連携していたか、悪意あるplain-crypto-jsが関連キャンペーンで積極的に使われていたことを示唆しています。

実際にリスクがあるのは誰か

公開期間は00:21〜03:29 UTCの約3時間で、これがリスクの範囲を決める重要な要素です。特にリスクが高いのは次のケースです。

• 依存関係のバージョンを固定せず、定期実行やコミット時にnpm installを実行するCI/CDパイプライン。特に、UTCの夜間や早朝に実行されるもの。

• その時間帯にnpm installまたはnpm updateを実行し、影響を受けるバージョンを取得した可能性のある開発者。

• @qqbrowser/openclaw-qbotまたは@shadanai/openclawに依存しているプロジェクト。この場合、公開期間に関係なく影響を受ける可能性があります。

ロックファイル（package-lock.jsonまたはyarn.lock）が悪意あるバージョンの公開前にコミットされており、インストール時に更新されていなければ、影響はありません。ロックファイルは、この攻撃に対する最初の防御線です。

悪意あるバージョンはnpmレジストリから削除されました。しかし、公開期間中にインストールした場合は、システム全体が侵害されたと考えてください。RATは稼働し、ビーコンを送信し、後続の任意のペイロードを実行できる状態でした。

Snykによる修復と侵害状況の確認方法

Snykのユーザーまたはお客様であれば、Snyk CLI、Snykアプリのインテグレーションなど、各種Snykインテグレーションを通じて、侵害された悪意あるaxios依存関係を含むプロジェクトを検出できます。

SnykのデータベースにはSNYK-JS-AXIOS-15850650とSNYK-JS-PLAINCRYPTOJS-15850652の両方が登録されているため、snyk testで影響を受けるバージョンと悪意ある間接依存関係を検出できます。

また、Enterpriseプランをご利用の場合、アプリケーションでゼロデイレポートを確認できます。以前のゼロデイセキュリティインシデントであるLiteLLM、Shai-Hulud、その他の事例と同様に、システム全体を把握して、脆弱なaxios依存関係を含む影響対象のプロジェクトやリポジトリを簡単に特定できます。

まだSnykをお使いでない場合も、無料プランですぐに利用を開始でき、次の手順でaxiosの侵害やその他のセキュリティ問題がないか環境を監査できます。

# Install Snyk CLI if you haven't already
npm install -g snyk

# Authenticate
snyk auth

# Test your project
snyk test

Bunをお使いの場合：Snykでの回避策（執筆時点ではSnyk CLIのネイティブbun.lockサポートは限定的です）：

推奨される回避策は、Bun組み込みの-yフラグを使ってyarn.lock互換のロックファイルを生成することです。Snykはこのファイルを解析できます。

# 1. Regenerate lockfile in yarn.lock format
bun install -y

# 2. Run snyk against the generated yarn.lock
snyk test --file=yarn.lock

それ以外の場合は、以下の手順でAxiosの侵害による影響の有無を確認できます。

手順1：ロックファイルで影響を受けるバージョンを確認する

# Check for axios 1.14.1 or 0.30.4
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Or with yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

手順2：悪意ある依存関係を確認する

# Look for plain-crypto-js in your dependency tree
npm ls plain-crypto-js

# Or search node_modules directly
find node_modules -name "plain-crypto-js" -type d

手順3：悪意あるAxios依存関係をインストールしたBunランタイムを確認する

Bunを使用している場合は、bun.lock（テキスト形式のロックファイル、Bun v1.1以降）を確認してください。

grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

悪意ある間接依存関係も確認してください。

grep 'plain-crypto-js' bun.lock

注：古いバージョンのBunでは、バイナリ形式のbun.lockbが生成されます。確認するには、まず変換してください。

> bun bun.lockb  # prints human-readable output to stdout
> bun bun.lockb | grep -E 'axios.*1\.14\.1|axios.*0\.30\.4'
> bun bun.lockb | grep 'plain-crypto-js'

手順4：侵害されたシステムでIOCを確認する

影響を受ける期間にマシンでnpm installが実行されたと思われる場合は、次の痕跡を探してください。

npmパッケージマネージャーでのその他の修復アドバイス

影響を受けていない場合（予防措置）：

1. package.jsonでaxiosのバージョンを安全と確認済みのものに固定してください。1.14.1または0.30.4以外のバージョンはすべて安全です。

2. ロックファイルをコミットし、CIでnpm installではなくnpm ciを使用して、ロックファイルの整合性を確保してください。

3. パッケージマネージャーまたはセキュリティツールのブロックリストにplain-crypto-jsを追加してください。

ライフサイクルフックが不要なCI環境では、npmインストール時に--ignore-scriptsを有効にすることを検討してください。

npm ci --ignore-scripts

これによりpostinstallスクリプトの実行を完全に防げるため、この攻撃経路を遮断できました。ただし、正当な理由でインストール後の処理が必要なパッケージ（ネイティブアドオンなど）が動作しなくなる場合があります。

さらに、依存関係をインストールする前にセキュリティと健全性のシグナルを事前確認できるオープンソースプロジェクトnpqの利用と、開発者への展開を検討してください。

最後に、公開されているnpmのセキュリティベストプラクティスを確認し、活用することをおすすめします。

影響を受けている場合（侵害された前提で対応）：

1. 直ちに封じ込める：影響を受ける期間にnpm installを実行したシステムを隔離してください。

2. すべてのシークレットをローテーションする：影響を受けたマシン上のすべての認証情報が侵害されたものとして扱ってください。APIキー、SSHキー、クラウド認証情報、npmトークン、GitHubトークンが対象です。同じ認証情報を更新するのではなく、失効させて再発行してください。

3. ラテラルムーブメントを調査する：sfrclak[.]comまたは142.11.206.73への外向き接続がないか、ログを確認してください。RATが稼働していた場合、攻撃者は任意のコードを実行でき、さらに情報を列挙または流出させた可能性があります。

4. 環境を再構築する：侵害されたシステムをクリーンアップしようとしないでください。安全が確認されたスナップショットまたはベースイメージから再構築してください。

5. CIパイプラインを監査する：2026年3月31日のUTC時間帯に関するビルドログを確認し、影響を受けるバージョンをインストールしたパイプラインを特定してください。

より大きな課題：メンテナーアカウントのセキュリティ

この攻撃は、今やよく知られた手口を踏襲しています。正規のメンテナーアカウントを侵害し、信頼されているパッケージの悪意あるバージョンを公開し、登録済みパッケージへのエコシステムの暗黙の信頼を悪用する手口です。同様の攻撃は、ESLintのPrettierプラグイン、フィッシングによる著名な開発者所有の複数パッケージ、そして600を超えるパッケージを侵害したShai-Huludキャンペーンでも確認されています。

Axiosが特に重大なのは、その利用規模の大きさです。週あたり1億回ダウンロードされるため、悪意あるコードが仕込まれた状態がわずか2時間続いただけでも、被害が広範囲に及ぶ可能性があります。攻撃者は、悪意ある依存関係を事前に準備し、「クリーン」なバージョン履歴を使い、ドロッパーを二重に難読化し、プラットフォームごとのRATを構築し、フォレンジック対策として自動削除を実装するなど、高度な運用能力も示しました。これは場当たり的な攻撃ではありませんでした。

オープンソースを大規模に利用する組織にとって、ここから得られる教訓は、npmの利用をやめたり、すべての依存関係を疑ったりすることではありません。ロックファイルの適用、postinstallスクリプトの監査、ビルド環境からの予期しないプロセス起動や外部ネットワーク接続を検知するランタイム監視など、どのサプライチェーン対策がこの攻撃を検知できたかを把握することです。今回のインシデントを踏まえ、Snykのnpmサプライチェーン攻撃を防ぐガイドとロックファイルのセキュリティに関する注意点を改めて確認することをおすすめします。

攻撃の仕組みを概念レベルで理解したい方は、攻撃パターンと防御策を解説する、Snyk Learnの正規パッケージの侵害に関するレッスンをご覧ください。

タイムライン