axios npm 1.14.1 / 0.30.4 のマルウェア混入と検出・修復の手順

はじめに

2026 年 3 月 31 日、世界で週 1 億回以上ダウンロードされる主要な HTTP クライアントライブラリ「axios」のメンテナアカウントが侵害され、悪意のある依存関係を含むバージョン（1.14.1 および 0.30.4）が npm レジストリへ公開されるサプライチェーン攻撃が発生しました。攻撃の稼働時間は 00:21 UTC から 03:25 UTC までの約 3 時間と短期間でしたが、174,000 を超える依存パッケージへの波及が懸念される深刻なインシデントとなりました。

参考: Mitigating the Axios npm supply chain compromise（Microsoft Security Blog）
“Microsoft Threat Intelligence has attributed this infrastructure and the Axios npm compromise to Sapphire Sleet, a North Korean state actor.”
（「Microsoft Threat Intelligence は、このインフラストラクチャと axios の npm 侵害を、北朝鮮の国家アクターである Sapphire Sleet に帰属させています。」）
https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/

本攻撃は、3 月に発生した Trivy 侵害を起点とする一連の TeamPCP キャンペーン（litellm へのマルウェア混入など）と時期が近接しているため混同されがちですが、Datadog Security Labs、Microsoft Threat Intelligence、Google Threat Intelligence Group の 3 社が独立して TTP（戦術・技術・手順）を分析した結果、両者は別のキャンペーンであると判断しています。axios 侵害の犯行は北朝鮮国家アクター UNC1069（Microsoft 命名: Sapphire Sleet）に帰属しており、使用されたマルウェアは WAVESHAPER.V2 と命名された情報窃取型 RAT です。

本記事では、axios 1.14.1 / 0.30.4 に注入された依存関係 plain-crypto-js の挙動、Windows / macOS / Linux 各プラットフォーム向け RAT の技術的特徴、自社環境の侵害有無を確認するためのコマンド、認証情報ローテーションの手順、CI/CD パイプラインを保護するための実践的な対策まで、運用者が必要とする情報を整理します。

axios を標的としたサプライチェーン攻撃の概要とタイムライン

今回の攻撃は、デコイパッケージの先行公開、本番ペイロードの段階的投入、両メジャーブランチへの同時侵害という、事前に周到に準備された段階的なキャンペーンとして実行されました。

攻撃の正確なタイムライン

Axios 公式 Post Mortem、Elastic Security Labs、Socket、StepSecurity の各社が観測した時系列を統合すると、以下の通りです。

特筆すべきは、plain-crypto-js@4.2.0 が悪性版公開の約 18 時間前に「クリーンなデコイ」として公開されていた点です。これは npm レジストリ上での公開履歴を確立し、信頼性の見せかけを作るための周到な準備作業でした。

axios（1.14.1 / 0.30.4）への不正な依存関係注入

axios は JavaScript エコシステムで最も広く利用されている HTTP クライアントの 1 つで、週 1 億回以上のダウンロードがあり、174,000 以上の npm パッケージが直接依存している主要ライブラリです。攻撃者は axios の主要メンテナ「jasonsaayman」のアカウントを侵害し、GitHub Actions の CI/CD パイプラインを介さずに、npm レジストリへ直接悪性バージョンを公開しました。

注入された変更は最小限です。axios 1.14.1 のソースコードは 1.14.0 と完全に同一で、package.json に plain-crypto-js@^4.2.1 という新しい依存関係が 1 行追加されただけでした。plain-crypto-js は axios のソースコード内で一切 import されておらず、唯一の役割は postinstall フックを介してマルウェアを実行することです。

参考: Compromised axios npm package delivers cross-platform RAT（Datadog Security Labs）
“The 1.14.1 source code is identical to 1.14.0. The only meaningful change to package.json was a new dependency: ‘plain-crypto-js’: ‘^4.2.1’, a name meant to resemble the legitimate crypto-js, never imported by any axios code.”
（「1.14.1 のソースコードは 1.14.0 と同一です。package.json への意味のある変更は、新しい依存関係 ‘plain-crypto-js’: ‘^4.2.1’ だけで、これは正規の crypto-js に似せた名前であり、axios のコードからは一切 import されていません。」）
https://securitylabs.datadoghq.com/articles/axios-npm-supply-chain-compromise/

メンテナアカウント侵害の経路と CI/CD パイプラインの迂回

Axios 公式 Post Mortem によると、メンテナの PC が標的型ソーシャルエンジニアリングと RAT マルウェアによって侵害され、これによって npm アカウントの認証情報が攻撃者の手に渡ったことが判明しています。

参考: Post Mortem: axios npm supply chain compromise（axios 公式 GitHub Issue #10636）
“The attacker gained access to the lead maintainer’s PC through a targeted social engineering campaign and RAT malware. This gave them access to the npm account credentials, which they used to publish the malicious versions.”
（「攻撃者は、標的型のソーシャルエンジニアリングキャンペーンと RAT マルウェアを通じて、リードメンテナの PC へのアクセスを得ました。これにより npm アカウントの認証情報を入手し、悪性バージョンの公開に使用しました。」）
https://github.com/axios/axios/issues/10636

攻撃者は侵害後、npm アカウントの登録メールアドレスを jasonsaayman@gmail.com から自身が管理する ifstap@proton.me に書き換えています。注目すべきは、正規の axios@1.14.0 が GitHub Actions OIDC trusted publishing と SLSA provenance で公開されていたのに対し、悪性版は OIDC を経由せず直接 CLI から publish された点です。npm レジストリのメタデータにこの差が記録されており、これが早期検出の鍵となりました。

クロスプラットフォーム RAT（WAVESHAPER.V2）の挙動

今回の攻撃で注入された不正な依存関係 plain-crypto-js は、OS の種類を判別して最適なマルウェアを実行する高度なドロッパーとして機能します。Google Threat Intelligence Group は本マルウェアを WAVESHAPER.V2 と命名しており、UNC1069 が以前から使用していた WAVESHAPER の更新版とされています。

二段階難読化された Node.js ドロッパー（setup.js）

postinstall フックで実行される setup.js（SILKBELL とも呼称、SHA-256: e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09）は、二層の難読化スキームで実装されています。

モジュール名、プラットフォーム識別子、ファイルパス、コマンドテンプレートなどの重要な文字列はすべて配列 stq[] にエンコード保存され、実行時にのみ復号されます。これは静的解析を困難にする目的で実装されています。

Windows / macOS / Linux ごとに最適化されたペイロード

ドロッパーは対象 OS を os.platform() で特定すると、それぞれ異なる手法でバックドアを設置します。3 つのプラットフォームのペイロードはすべて同一の RAT を異なる言語で実装したもので、C2 プロトコル、コマンドセット、ビーコン頻度、偽装 User-Agent はすべて共通です。

各プラットフォームは、同一の C2 サーバ sfrclak[.]com:8000 の共通エンドポイント /6202033 に対して、プラットフォーム識別子（packages.npm.org/product0、product1、product2）を含む POST リクエストを送信します。packages.npm.org/ プレフィックスは、ネットワークログ上で正規の npm レジストリ通信に見せかける偽装手法です。

参考: Inside the Axios supply chain compromise – one RAT to rule them all（Elastic Security Labs）
“All three stage-2 payloads are implementations of the same RAT — identical C2 protocol, command set, beacon cadence, and spoofed user-agent, written in PowerShell (Windows), C++ (macOS), and Python (Linux).”
（「3 つの第 2 段階ペイロードはすべて同一の RAT の実装です。C2 プロトコル、コマンドセット、ビーコン頻度、偽装 User-Agent はすべて同一で、PowerShell（Windows）、C++（macOS）、Python（Linux）でそれぞれ実装されています。」）
https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all

60 秒間隔のビーコンと偽装 User-Agent

各 RAT は起動時に 16 文字のランダムな被害者 ID を生成し、システム情報（ホスト名、ユーザー名、OS バージョン、タイムゾーン、CPU タイプ、稼働プロセス、ディレクトリ一覧）を収集します。その後、60 秒間隔で C2 へ HTTP POST ビーコンを送信します。

ビーコンの User-Agent は mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0) という、Windows XP 上の Internet Explorer 8 を装う偽装文字列です。現代の環境ではほぼ存在しない構成のため、ネットワークログでこの User-Agent を検出すれば侵害の強い兆候となります。

postinstall フックの悪用と自己破壊型の隠蔽工作

このマルウェアの特徴的な点は、npm の postinstall ライフサイクルを悪用していることと、実行後の徹底したフォレンジック妨害です。ペイロードの実行が完了すると、マルウェアは以下の操作を実行して証拠を消去します。

• 自身の setup.js を削除
• package.json を package.md（クリーンな 4.2.0 マニフェスト相当の偽装ファイル）で上書き
• node_modules/plain-crypto-js/package.json から postinstall トリガーの痕跡を消去

事後に node_modules/plain-crypto-js/package.json を調査しても、postinstall フックの痕跡は残っていません。 このため、node_modules のスナップショット監査だけでは「何も実行されていない」と誤判定するリスクがあります。

Linux RAT のコンテナ環境におけるクラッシュバグ

Linux RAT はコンテナ化された環境（Docker / Kubernetes）でクラッシュするバグを持つことが Datadog Security Labs によって報告されています。コンテナベースの CI ランナー上では RAT 起動が失敗した可能性が高い一方、ローカル開発機（macOS、Windows、ベアメタル Linux）では RAT が正常に動作するため、開発者個人の PC こそが実際の侵害ポイントになっている点には留意が必要です。

自社環境への影響確認とコマンドレベルの対処手順

axios はフロントエンドからバックエンドまで広く利用されているため、影響範囲の特定と初動対応のスピードが被害を最小限に抑える観点で重要です。

# package-lock.json から汚染パッケージを検出
grep -E '"axios": "(1\.14\.1|0\.30\.4)"|plain-crypto-js' package-lock.json

# yarn.lock の場合
grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" yarn.lock

# pnpm-lock.yaml の場合
grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" pnpm-lock.yaml

# モノレポなど複数のロックファイルが存在する場合は再帰的に検索
find . -name "package-lock.json" -exec grep -l "plain-crypto-js" {} \;
find . -name "yarn.lock" -exec grep -l "plain-crypto-js" {} \;

# プロジェクト配下から汚染パッケージの物理存在を確認
find . -path '*/node_modules/plain-crypto-js' -type d 2>/dev/null

# axios の package.json を抽出してバージョンを確認
find . -path '*/node_modules/axios/package.json' \
  -exec grep -l '"version": "\(1\.14\.1\|0\.30\.4\)"' {} \;

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "macOS RAT FOUND"

# Linux
ls -la /tmp/ld.py 2>/dev/null && echo "Linux RAT FOUND"
ps aux | grep -E "/tmp/ld\.py" | grep -v grep

# Linux: C2 への通信プロセスの確認
ss -tnp 2>/dev/null | grep -i sfrclak

# Windows（PowerShell）
# Get-Item "$env:PROGRAMDATA\wt.exe" -ErrorAction SilentlyContinue
# Get-NetTCPConnection -State Established | Where-Object {$_.RemotePort -eq 8000}

# 1. 既存の node_modules とロックファイルを完全に削除
rm -rf node_modules package-lock.json
npm cache clean --force

# 2. package.json で安全版を明示的に指定（caret range を外して固定）
# 編集対象:  "axios": "^1.14.0" → "axios": "1.14.0"
#           "axios": "^0.30.0" → "axios": "0.30.3"

# 3. overrides ブロックで推移的依存も封じる（package.json に追記）
# "overrides": {
#   "axios": "1.14.0",
#   "plain-crypto-js": "npm:dne@1.0.0"
# }

# 4. クリーンインストール
npm install

# 5. インストール結果の検証
grep -E '"axios"' package-lock.json
grep "plain-crypto-js" package-lock.json && echo "WARNING: still infected"

# GitHub Actions の侵害ウィンドウ内ジョブを抽出
gh run list --repo <OWNER>/<REPO> \
  --created "2026-03-31T00:21:00Z..2026-03-31T03:25:00Z" \
  --json conclusion,createdAt,name,url

# 組織横断で axios を参照しているリポジトリを検索
gh search code "axios" --owner <YOUR_ORG> --extension json --filename package.json

対処時に注意すべきハマりポイント

axios 侵害の対処では、表面的な対応では侵害が残存するケースが複数報告されています。以下のポイントは特に見落とされやすいため、対処手順に組み込むことが推奨されます。

caret range（^1.14.0）でピン留めしていた環境は自動的に汚染版に更新された

package.json で "axios": "^1.14.0" のように caret range を指定していた環境では、侵害ウィンドウ中に新規の npm install を実行すると、自動的に 1.14.1 が解決されて汚染版が取り込まれました。 同様に "axios": "^0.30.0" の指定でも 0.30.4 が解決されています。

Datadog の State of DevSecOps レポートによると、約 50% の組織が新規パッケージリリース後 24 時間以内に第三者ライブラリを取り込んでいるとされており、今回の 3 時間という短い侵害ウィンドウでも相応の被害が発生したと推定されます。caret range を使っていた環境では、ロックファイル監査が侵害有無の判定に必須となります。

両方のメジャーブランチ（1.x と 0.x）が侵害された

攻撃者は意図的に最新版（1.14.1、latest タグ）と legacy 版（0.30.4、legacy タグ）の両方を 39 分間隔で公開しており、「古いバージョンを使っているから安全」という思い込みは今回のケースでは通用しません。

Linux RAT はコンテナ環境でクラッシュするバグを持つ

Linux RAT はコンテナ化された環境ではクラッシュするバグが確認されています。CI ログだけ見て「クラッシュしているから問題ない」と判断するのは危険です。侵害ウィンドウ内に npm install を実行した開発者全員の PC を監査対象とすることが推奨されます。

GitHub のソースコード監査では検出不可能

axios リポジトリの GitHub 上のソースコードには悪性コードが一切コミットされていません。 攻撃者は侵害された npm アカウントから直接レジストリへ publish しており、Git 履歴には変更が残っていません。Git のコミット履歴チェック、SAST スキャン、コードレビューでは今回の侵害は発見できません。

自己破壊型ペイロードによりフォレンジック調査が困難

postinstall 実行後、setup.js は自身を削除し、package.json を package.md で上書きします。node_modules のスナップショット監査だけでは「実行された痕跡なし」と誤判定するリスクがあります。ロックファイルに plain-crypto-js の記録が残っているかどうかを主軸に判定することが推奨されます。

推移的依存（transitive dependency）として混入するケース

直接 package.json に axios を記載していない場合でも、サードパーティパッケージの推移的依存として汚染版が取り込まれた可能性があります。

# 依存ツリー全体での axios の有無を確認
npm ls axios

# 逆依存の可視化
npm ls axios --all

axios 侵害（UNC1069）と litellm 侵害（TeamPCP）の比較

axios 侵害と、3 月初旬に発生した TeamPCP による litellm へのマルウェア混入事件 は、時期が近接しているため一連のキャンペーンと混同されがちです。しかし Datadog Security Labs、Microsoft、Google GTIG の 3 社が独立して TTP を分析した結果、両者は別の攻撃グループによる無関係なキャンペーンと判断されています。

参考: Compromised axios npm package delivers cross-platform RAT（Datadog Security Labs）
“Note on TeamPCP: The TTPs in this compromise do not match the recent TeamPCP supply chain campaign that targeted Trivy, LiteLLM, Telnyx, and Checkmarx earlier in March 2026. We assess with reasonable confidence that these are unrelated campaigns.”
（「TeamPCP に関する注記: この侵害の TTP は、2026 年 3 月初旬に Trivy、LiteLLM、Telnyx、Checkmarx を標的とした最近の TeamPCP サプライチェーンキャンペーンと一致しません。これらは無関係なキャンペーンであると、合理的な確度で評価しています。」）
https://securitylabs.datadoghq.com/articles/axios-npm-supply-chain-compromise/

この比較が示唆するのは、2026 年に入ってからオープンソースサプライチェーンが「複数の異なる攻撃グループから同時並行で標的とされている」という事実です。単一キャンペーンへの対策だけでなく、メンテナアカウント保護、依存関係ピン留め、postinstall フック制限、ネットワーク egress 制御といった多層的な防御が、業界全体の課題となっています。

CI/CD パイプライン保護と多層防御の実装

今回の axios 侵害で特徴的なのは、ソースコード自体には一切の変更が加えられていない（依存関係の追加のみ）という点です。

参考: Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account（The Hacker News）
“The attack is notable for its restraint. No axios source files were modified, making traditional diff-based code review less likely to catch it.”
（「この攻撃は、その抑制力において注目に値します。axios のソースファイルは変更されていないため、従来の diff ベースのコードレビューでは発見される可能性が低くなります。」）
https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html

dependency cooldown による新規パッケージの隔離

npm（v10 以降）と pnpm、Bun などの主要パッケージマネージャは、dependency cooldown 機能をサポートしています。これは「公開直後の新規パッケージを一定期間（通常 24〜48 時間）取り込まない」設定で、コミュニティが悪性パッケージを検出してフラグするまでの猶予期間を確保する効果があります。

# npm の例（.npmrc に設定）
echo "minimum-release-age=86400" >> .npmrc  # 24 時間（秒単位）

今回のケースでは、plain-crypto-js@4.2.1 公開から悪性版 axios 公開までの間隔がわずか 22 分でした。dependency cooldown を 24 時間に設定していた環境では、Socket やコミュニティが悪性版をフラグした後の解決となるため、汚染を回避できた可能性があります。

OIDC trusted publishing への移行

Microsoft Threat Intelligence が推奨する根本的な対策の 1 つが、長期保管型の npm token を廃止し、OIDC ベースの trusted publishing に移行することです。OIDC trusted publishing は、CI/CD プラットフォームとレジストリ間でジョブごとに発行される短寿命トークンを使うため、メンテナ個人の PC が侵害されても publish に必要な認証情報は窃取されない設計となっています。

参考: Mitigating the Axios npm supply chain compromise（Microsoft Security Blog）
“Adopt Trusted Publishing with OIDC to eliminate stored credentials.”
（「保管された認証情報を排除するため、OIDC による Trusted Publishing の採用を推奨します。」）
https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/

postinstall フックの実行制限

axios 侵害の根本的な攻撃ベクターは、npm の postinstall ライフサイクルフックでした。CI/CD 環境では以下の設定でその実行を制限することが推奨されます。

# CI 環境で postinstall を無効化
npm install --ignore-scripts

# .npmrc に永続設定
echo "ignore-scripts=true" >> .npmrc

ただし、puppeteer、node-gyp 等の legitimate な postinstall に依存しているパッケージもあるため、本番ビルドでは ignore-scripts を有効化し、特定パッケージは allowlist で個別許可する設計が推奨されます。

コンテナ実行環境の Egress 通信制御

RAT は外部 C2 サーバ（sfrclak[.]com など）からペイロードをダウンロードしビーコンを送信することで成立します。Egress 通信先を必要最小限のホワイトリストに絞ることで、RAT の活動を遮断する効果が期待できます。AWS Network Firewall、Azure NSG などで FQDN ベースのアウトバウンド制御を設定し、npm レジストリ（registry.npmjs.org）と正規連携先のみを許可する構成が有効です。

Trivy 関連サプライチェーン攻撃との防御策の共通点

axios 侵害と TeamPCP キャンペーンは別の攻撃グループによるものですが、両者ともに「メンテナアカウント乗っ取り → 直接 publish」という同一の攻撃パターンを採用しており、防御策の方向性は共通しています。CI/CD パイプライン全般のセキュリティ強化策については、関連記事『Trivy 関連サプライチェーン攻撃と CI/CD 防御策』も参照してください。

公式アドバイザリと参考情報

本攻撃に関する一次情報および詳細な技術解説は、以下のソースから入手できます。

まとめ

本記事では、北朝鮮国家アクター UNC1069 による axios npm パッケージへのサプライチェーン攻撃と、自社環境の検出・修復・対策について解説しました。

• 2026 年 3 月 31 日 00:21〜03:25 UTC（約 3 時間）の間、axios 1.14.1 / 0.30.4 が悪性版として npm に公開された
• 攻撃は北朝鮮国家アクター UNC1069（Sapphire Sleet）に帰属し、TeamPCP / Trivy 関連キャンペーンとは無関係である
• メンテナ PC への標的型 RAT 感染で npm 認証情報が窃取され、OIDC を経由せず直接 publish された
• 注入された plain-crypto-js は postinstall で WAVESHAPER.V2 RAT を起動し、Windows / macOS / Linux に展開する
• 影響確認はロックファイル監査（package-lock.json / yarn.lock / pnpm-lock.yaml）を主軸とする
• caret range 利用環境は自動的に汚染版へ更新されたため、ロックファイルの記録が判定の決め手となる
• 対策は dependency cooldown、OIDC trusted publishing、postinstall 制限、Egress 通信制御の組み合わせが有効

以上、最後までお読みいただきありがとうございました。